Registered office
20 Wenlock Road
London N1 7GU
Choose off-the-shelf software when a proven product fits the important workflow with tolerable change; choose custom software when the workflow creates real competitive value, cannot be supported safely by available products, or repeated workarounds now cost more than ownership. The answer is often a hybrid: buy the commodity capability and build only the differentiating layer.
Reviewed: 9 September 2026
Custom software vs off-the-shelf at a glance
| Question | Off-the-shelf | Custom |
|---|---|---|
| Time to initial use | Usually faster if configuration is straightforward | Longer because discovery, design, build and testing are required |
| Upfront cost | Usually lower | Usually higher |
| Workflow fit | You adapt to the product’s model | The product can follow an evidenced workflow |
| Roadmap control | The vendor controls priorities and retirement | You control priorities but must fund stewardship |
| Maintenance | Vendor operates the core; your configuration still needs ownership | Your organisation owns or commissions the full lifecycle |
Start with the problem, not the product label
A request for custom software may actually be a reporting, integration or process problem. A request to buy a platform may hide requirements that no standard product serves. Define the users, outcome, volume, exceptions, risk and existing systems before choosing a route.
GOV.UK’s guidance on commercial off-the-shelf products recommends discovery before committing to technology and checking user needs, accessibility and sustainability. That principle works for private businesses too: understand the service first, then test whether buying, building or combining products is the best fit.
When off-the-shelf software is the stronger choice
Buying is attractive when the need is common and mature: payroll, accounting, commodity CRM, team collaboration or service desk work, for example. A reputable vendor can spread security, compliance and feature investment across many customers. Implementation can concentrate on configuration, migration, permissions, training and adoption.
But “ready-made” does not mean “zero project”. Test:
- whether the standard workflow handles normal and exceptional cases;
- licence, storage, API, support and implementation costs;
- identity, permissions, audit logs, export and retention controls;
- integration limits and rate limits;
- accessibility and usability for the actual workforce;
- data location, processor terms and exit options;
- the vendor’s release, support and product-retirement model.
When custom software earns its place
Custom development is easier to justify when the process is distinctive, high-volume or tightly connected to how the business competes. It may also be appropriate when safety, privacy or operational requirements cannot be achieved through sensible configuration, or when staff maintain an expensive shadow system of spreadsheets and manual reconciliation around the purchased product.
The benefit is control over user experience, integrations, rules and roadmap. The obligation is long-term ownership. Custom software needs product decisions, secure development, tests, monitoring, documentation, support and planned upgrades. NCSC’s Software Security Code of Practice assurance principles provide useful questions about secure design, build, deployment and maintenance.
Compare total cost, not purchase price
Model three to five years where practical. For packaged software, include licences, implementation, add-ons, integrations, training, administration, price changes and exit. For custom software, include discovery, delivery, hosting, third-party services, maintenance, security, monitoring, user support and eventual replacement.
Also count the operational gap. If staff re-key information, reconcile exports or wait for a supplier to change a small rule, that has a measurable cost. Conversely, do not assign imaginary savings to automation without observing the current workload and error rate.
The hybrid option is often overlooked
A business can use standard identity, payments, accounting or CRM services and build a focused workflow around them. This avoids recreating commodity capabilities while preserving the part that differentiates the service. The architecture must still account for failure: what happens when an API is unavailable, a vendor changes a field or the business needs to export its data?
Low-code tools can also form part of the mix. Read low-code versus custom software for workflows before treating a visual builder as either a complete shortcut or an unsuitable toy.
A practical decision scorecard
- Document the outcome. What improves for the user and how will it be measured?
- Observe the workflow. Include volumes, hand-offs, exceptions, approvals and failure recovery.
- Test real products. Use a scripted demonstration based on your scenarios, not a generic sales tour.
- Score fit and risk. Weight mandatory needs separately from preferences.
- Model whole-life cost. Include people, change, integration, support and exit.
- Run a small proof. Validate the riskiest assumption before a broad rollout or build.
ACA’s software discovery workshop is designed for this decision stage: it maps the service, risks, scope and sensible first release without assuming custom build is the answer.
Questions to ask a vendor or development partner
- Which requirements are standard, configured, extended or unavailable?
- Who owns data, source code, environments and administrator accounts?
- How are security updates, incidents and breaking changes handled?
- What evidence will show the implementation works?
- What grows the cost: users, records, transactions, environments or support?
- How can the business leave with usable data and documentation?
See ACA’s broader software and digital development services for websites, mobile products, ecommerce and integrations.
Frequently asked questions
Is custom software always more expensive?
It usually has a higher initial cost, but the meaningful comparison includes licences, workarounds, integration, administration and exit over the expected life of the service.
Can off-the-shelf software be customised?
Often it can be configured or extended, but deep customisation can make upgrades and support harder. Confirm what remains within the vendor’s supported path.
Who owns custom software?
The contract should state ownership and licensing for source code, design, third-party components, infrastructure and data. Do not assume payment alone answers every ownership question.
Should we replace our process before automating it?
Remove unnecessary steps and define ownership first. Software can make a sound process faster, but it can also scale confusion.
