Custom software vs off-the-shelf: which should your business choose?

Choose a standard product when the process can fit

Buying can be sensible for a familiar process with supported configuration, usable reporting and a commercial model the business can sustain. The team may benefit more from adopting a consistent workflow than reproducing every historical workaround in code.

Ask the vendor to demonstrate the awkward parts: a corrected record, removed employee access, a failed integration and an export of your data. Confirm which features require another plan or add-on and which actions need supplier support.

Do not reject an otherwise suitable product because its screens differ from the current spreadsheet. Distinguish essential business rules from preferences. The internal-tool versus SaaS guide covers that narrower employee-workflow decision; this comparison includes broader applications and replacement choices.

Choose custom work for material unmet requirements

Custom software may fit when the core customer journey, approval rules or system relationships cannot be supported adequately by a packaged product. State the unmet requirement and its business consequence. “We want full flexibility” is not yet a scope.

Keep the first release focused. Every configuration option and exception built into the product becomes something to explain, test and maintain. The custom software buyer guide helps define the operating context, and feature prioritisation helps narrow the first outcome.

Custom is a poor choice if the business cannot assign a decision owner, support the service or fund maintenance. It is also premature when a simple process change has not been tested. Source-code access is valuable, but it does not replace an operating team.

Keep a working system and build the missing journey

A hybrid approach uses a packaged system for established records or functions and adds a focused application around a missing interaction. This can preserve useful capabilities without forcing the business to accept every interface limitation.

Hypothetical example: a service business keeps its existing job-management system but adds a customer request and status portal. The portal owns the customer interaction; the agreed system remains responsible for job records. Test access, update authority and failure recovery at that boundary.

Hybrid is not automatically simpler. Two systems need consistent identifiers, supported interfaces and clear responsibilities. Use the existing-system application guide and client portal service when that is the actual missing capability.

Compare the whole period you expect to use it

Choose the same planning horizon and usage assumptions for both options. List initial work, recurring charges, supplier usage, integration maintenance, internal administration, support, migration and eventual exit. Ask providers to estimate the defined scenario rather than comparing a licence price with a complete development proposal.

For packaged software, check data export, account cancellation, price-change terms and API access. For custom work, check intellectual-property terms, dependency licences, repository access, deployment credentials and whether another team can maintain the product. Agree terms with the appropriate commercial adviser.

AI-assisted coding does not make lifecycle responsibilities disappear. Evaluate the demonstrated result and maintainability of any custom layer, not the volume of code generated. GOV.UK’s technology-choice guidance provides useful context for making technology decisions around service needs rather than a preferred tool.

Run a bounded fit test before committing

1. Select a representative journey: use approved sample data and include an important exception.
2. Demonstrate the packaged option: record what works, what needs configuration and what is unsupported.
3. Define only the custom gap: identify the data, permissions and interfaces it requires.
4. Compare operation: ask who handles failures, updates, access removal and data recovery.
5. Record the decision: choose buy, configure, hybrid, build or investigate, with assumptions and acceptance evidence.

Use relevant OWASP ASVS requirements as part of a technical security discussion for either approach. A product label or custom implementation is not proof of security.

LCR’s recommendation is to preserve what works and build only the capability that earns its complexity. Review the delivery checklist before accepting a custom release, or discuss the unresolved workflow before choosing an implementation route.

Questions

Frequently asked questions