A build vs buy software discussion often starts too late. Someone has already chosen a product, sketched a custom platform or promised a delivery date. The meeting then becomes a defence of preferred solutions rather than a test of the underlying need.
A better decision starts with the job the software must perform. It then tests four realistic paths: buy a product, configure a product, combine bought and custom components, or build a tailored system. The correct answer may differ by capability. A team can buy identity and payments, for example, while building the workflow that makes its service distinctive.
This framework uses five gates: Need, Fit, Connection, Ownership and Exit. Each gate ends with evidence that can be reviewed by product, operational, commercial and technical stakeholders. It does not produce a universal winner. It exposes where an apparently simple choice transfers cost, constraint or responsibility to another part of the organisation.
Gate 1: Define the Need Without Describing a Product
Write the problem as an observable outcome before comparing suppliers or estimating a build. “We need a new CRM” describes a solution category. “Account managers need one reliable view of customer conversations and next actions” describes the job.
Capture the current route through the work:
- Trigger: What starts the process?
- People: Who performs, approves or receives the work?
- Information: What data enters, changes and leaves the process?
- Exceptions: Which cases fall outside the normal path?
- Outcome: What must be true when the work is complete?
- Constraint: Which legal, security, accessibility or operational boundaries cannot be traded away?
Separate requirements into three groups. Commodity requirements are mature capabilities that many products already provide. Differentiating requirements shape the organisation's service or operating model. Accidental requirements exist only because of a workaround, legacy limitation or habit. Treating all three as equally special can make a build unnecessarily broad. Treating all three as commodity can force the organisation to redesign useful work around a supplier's product.
The UK Government's Technology Code of Practice begins with user needs and also asks teams to consider accessibility, security, privacy, integration, data, purchasing and sustainability across the technology lifecycle. It is written for government, but those questions provide a useful discipline for any UK organisation preparing a software decision.
Gate evidence: A one-page problem statement, a map of the current workflow, prioritised requirements and named constraints. If stakeholders cannot agree on these, product comparisons are premature.
Gate 2: Test Real Product Fit, Not Feature-List Fit
A supplier's feature list shows that a capability exists. It does not show whether the capability works with the organisation's data, permissions, terminology, exception paths or approval rules.
Use a short scenario-based assessment. Choose three to five tasks that represent normal work, a difficult exception and a control-sensitive action. Ask each shortlisted supplier to demonstrate those scenarios using realistic roles and sample data. Record whether each step is available as standard, configurable, dependent on an add-on, reliant on manual work or unavailable.
Score the gaps by consequence rather than count. A product with ten cosmetic gaps may fit better than one with a single gap that prevents a required approval, accessible journey or auditable decision. For each material gap, choose one response:
- Adapt the Process: Appropriate when the existing step adds little value and the product offers a simpler controlled route.
- Configure the Product: Appropriate when supported configuration meets the need without creating a fragile upgrade path.
- Integrate a Component: Appropriate when another system already owns the required capability or data.
- Build the Missing Workflow: Appropriate when the gap is important, specific and unlikely to be served well by the product roadmap.
- Reject the Option: Appropriate when a non-negotiable need remains unmet.
Do not treat extensive configuration as automatically safer than custom code. Configuration still requires design, testing, ownership and change control. It can also become difficult to understand when business rules are scattered across fields, plug-ins and supplier-specific automation.
Gate evidence: A scenario scorecard, a documented response to every material gap and written confirmation of which features are standard, configured, integrated or custom.
Gate 3: Measure the Connection Work
Software rarely operates alone. Before choosing a route, draw the boundary around identity, data, notifications, reporting, finance, customer channels and operational support. Then trace what must cross that boundary.
For every connection, record:
- The system that owns the authoritative record.
- The data format and transfer method.
- The frequency and acceptable delay.
- The identity and permission model.
- Failure behaviour and the person alerted.
- Reconciliation when two systems disagree.
- Export, retention and deletion requirements.
The Government Digital Service says open standards can improve interoperability and help avoid vendor lock-in in its guidance on using open standards. That does not mean every proprietary interface is unacceptable. It means the decision should identify where a supplier-specific format or service creates a dependency and whether its value justifies the switching effort.
If a product meets most visible requirements but cannot exchange data reliably with core systems, the integration may become the real product. A hybrid route can be sensible: retain a mature bought capability while using a focused web application to coordinate a distinctive workflow. The boundary must remain deliberate. A custom layer that merely hides an unsuitable product can preserve the product's constraints while adding another system to maintain.
Gate evidence: A context diagram, interface list, data ownership decisions, failure handling and an estimate of the work needed to migrate and reconcile data.
Gate 4: Assign Lifecycle Ownership and Compare Whole Costs
Purchase price and initial development effort are only the visible portion of the decision. Compare the responsibilities each option creates over an agreed period. Avoid invented precision: use ranges, assumptions and named owners where the evidence is incomplete.
The comparison should cover:
- Acquisition: Subscription, licences, discovery, procurement and contracting.
- Implementation: Configuration, development, integration, migration, testing and accessibility review.
- Adoption: Training, operational change, documentation and support during transition.
- Operation: Hosting, monitoring, incident response, supplier management and user support.
- Change: Product releases, regression testing, backlog ownership and new integrations.
- Assurance: Security review, privacy controls, audit evidence and business continuity.
- Exit: Data export, contract termination, replacement, archive and decommissioning.
Buying transfers some product development and operation to a supplier; it does not transfer accountability for choosing, configuring and governing the service. Building creates direct control over priorities but also requires a credible owner for maintenance, security updates, operational support and eventual replacement.
Where a supplier processes personal data on the organisation's behalf, the ICO states that the relationship must be governed by a written contract and explains equivalent obligations for authorised sub-processors in its controller–processor contract guidance. The precise roles depend on the processing activity, so the responsible privacy or legal adviser must confirm them.
For a custom route, define who owns the source code, infrastructure, documentation, deployment access and product backlog. A custom software development partner can deliver the system, but the organisation still needs enough knowledge and access to operate, change or transfer it responsibly.
Gate evidence: A lifecycle responsibility matrix, a range-based cost model with assumptions, a support model and named owners for product, technical, data, security and supplier decisions.
Gate 5: Test the Exit Before Signing or Building
An exit plan is not a prediction that the decision will fail. It is a test of whether the organisation understands its dependency.
GOV.UK guidance on managing technical lock-in distinguishes commercial lock-in from technical lock-in and recommends balancing the value of a provider-specific service against switching difficulty. It also notes that avoiding all lock-in can reduce useful functionality or add engineering cost. The practical goal is conscious dependency, not theoretical portability at any price.
Run a tabletop exit exercise for each serious option:
- Trigger the Exit: Assume the supplier changes terms, a strategic requirement changes, or the system no longer meets the need.
- Retrieve the Assets: List the data, configuration, code, documentation, audit records and credentials the organisation can obtain.
- Read the Output: Confirm formats, relationships, attachments, history and identifiers remain usable outside the system.
- Continue the Service: Identify how operations run during migration and how changes are synchronised.
- Remove the Old System: Define retention, deletion, access revocation and contract closure.
- Estimate the Switch: Record the people, elapsed time, dependencies and unavailable knowledge that would shape the move.
For a custom build, replace “supplier export” with a handover test. Can a competent team deploy the system from documented source, understand its interfaces, recover it from backup and operate it without relying on one individual? Ownership on paper is weak if the organisation cannot exercise it.
Gate evidence: Contractual exit terms, verified export or handover samples, a continuity approach and a switching-cost range reviewed by commercial and technical owners.
Use a Four-Route Decision Record
After the five gates, compare all four routes rather than forcing a binary choice.
| Route | Strongest When | Main Risk to Test | | --- | --- | --- | | Buy | The need is common and a product fits important scenarios with limited change. | Supplier dependency, integration limits and roadmap control. | | Configure | A mature platform supports the workflow through governed, upgrade-safe configuration. | Hidden complexity and fragile customisation. | | Combine | Commodity capabilities can be bought while a focused custom layer handles distinctive work. | Boundary ownership, duplicated data and integration failure. | | Build | The workflow is genuinely differentiating or products fail non-negotiable needs. | Long-term product ownership, maintenance and support capacity. |
Record the rejected routes and the evidence that ruled them out. Add assumptions that could reverse the choice, such as user growth, a supplier roadmap commitment, a regulatory change or the loss of an internal skill. Set a review date. A sound decision can become unsound when its assumptions change.
The Final Review
A decision is ready when stakeholders can answer five questions with evidence:
- Need: Is the outcome clear without naming a preferred product?
- Fit: Have realistic scenarios exposed material gaps and exceptions?
- Connection: Are data, identity, integrations and failure paths understood?
- Ownership: Does every lifecycle responsibility have a credible owner?
- Exit: Can the organisation retrieve what it needs and continue the service?
If one answer is no, reopen that gate rather than compensating with a confident forecast. The purpose of the framework is not to make custom development win. It is to prevent a quick purchase, a broad build or an accidental hybrid from hiding the work the organisation will still own.
Teams that need help defining the boundary can review illustrative delivery scenarios or contact Programmers House to discuss the problem, constraints and ownership model before choosing a route.