Off-the-shelf software or a custom system: how do you decide?
This is not a blind choice between two extremes. Compare a ready-made product, configuration, integration, and custom development against the same business criteria.
AT A GLANCE
Choose off-the-shelf software when it covers the important workflows with acceptable compromises, integrates safely, and has a sustainable total operating cost. A custom system is justified when distinct business rules, roles, or data connections cannot be handled well by an existing product. Configuration or a hybrid approach is often the sensible first step.
- Test every option against the same real workflow.
- Include licensing, integration, migration, and operation as well as implementation.
- Build custom software only around differences with business value.
Define the decision before comparing products
Do not start with product names or feature lists. Choose one complete, common case and document its trigger, data source, roles, approvals, exceptions, and completion. Test that same workflow against every plausible option. The useful choice is not the longest feature list; it is the option that supports important work with the fewest risky workarounds.
Separate a genuinely differentiating business rule from habit. Doing something the same way for years does not by itself justify custom development. Ask what would happen if the process adapted to a standard product. If that would remove necessary accountability, customer experience, or control, the difference may have real business value.
There are four paths, not two
The first option is a ready-made product with no changes. The second is configuring its permissions, fields, and workflows. The third is integrating existing systems with clear sources and ownership. The fourth is custom development. Hybrid solutions are common too: a standard service handles standard work while a smaller custom interface coordinates the distinct workflow.
Run a short trial of the two or three viable options. Use the same anonymised examples to test a normal case, missing data, duplicates, permission errors, and reporting needs. If a product fits daily work only through exports and manual copying, do not automatically classify it as the cheaper option.
Compare total cost of ownership
Implementation price is one line. For a product, include per-user or usage fees, the required plan, configuration, integration, migration, training, and possible supplier price changes. For custom software, include discovery, development, hosting, monitoring, backups, security updates, corrections, and future improvements. Both options need a named operational owner.
Use the same period and scope for each comparison. Mark confirmed costs separately from estimates. Do not convert released working time into an automatic cash saving; observe how the team uses it. Fewer stalled cases and quicker retrieval of decisions can also matter, but they require a baseline.
Examine data, access, and the exit path
Document which data enters the system, who may read or change it, how long it must be retained, and how it can be exported. For personal data, minimisation and restricted access by default belong in the design. Custom development needs security throughout its lifecycle; with a product, you still need to verify your own configuration and responsibilities rather than relying only on supplier claims.
Plan the exit too. In what format can data be retrieved, does the event history remain usable, can access be revoked, and what happens when an integration stops? Open, documented interfaces can reduce the cost of changing direction. Ownership alone is insufficient: usable documentation, source access, backups, and a handover process also matter.
Make an evidence-based, reversible decision
Create a short decision table. Give each critical user task, mandatory business rule, integration, privacy condition, total cost, operational owner, and exit option its own row. Support each claim with a trial result, contract term, or documented assumption. Words such as “flexible” and “easy to integrate” are not evidence by themselves.
If a product covers the critical work, configure or integrate it first. If a decisive difference demonstrably cannot be handled, a focused custom module may be the next step. Commit to a complete custom system only when its value, long-term owner, and operating cost are clear. A sound decision can be revised when new evidence appears.
A PRACTICAL TEMPLATE
Buy–configure–integrate–build decision matrix
Use the same criteria to record evidence, costs, ownership, and exit conditions for all four paths. The template does not score the options for you; weights must reflect your own business situation.
- Critical user task
- Total operating cost
- Data and access
- Exit path
Sources and further reading
- Choose the right tools and technologyGOV.UK Service Manual · Checked: 2026-10-31
- Define your purchasing strategyUK Government Digital Service · Checked: 2026-10-31
- Secure Software Development Framework (SSDF) Version 1.1NIST · Checked: 2026-10-31
- General Data Protection Regulation, Article 25European Union · Checked: 2026-10-31
Related questions
When is custom software better than an off-the-shelf product?
Custom software is the better option when a product can handle critical business rules, roles, or data connections only through compromises that weaken control, customer experience, or operational reliability. Test a ready-made product, configuration, and integration against the same real workflow first.
How do you compare ready-made and custom business systems?
Use the same period and scope to compare implementation, licences, configuration, integration, migration, training, monitoring, security updates, and the exit path. Every option should have a documented trial, a named owner, and uncertainty shown separately from confirmed facts.
Borbély Kristóf
The developer behind Kriside, writing practical guides about web systems, automation, and AI solutions.