Build vs Buy Is the Wrong Question for Digital Product Capabilities

“Build or buy?” compresses a consequential product decision into two verbs. It hides configure, reuse and defer, then encourages a spreadsheet to declare a winner.

The real choice is which capability the organisation should own, which burdens it can carry, and how it will recover if today’s answer stops working.

This is not procurement theatre. Sourcing changes the product’s constraints: speed of learning, data control, reliability, unit economics and the promises a team can make.

The decision belongs to product and engineering together. Commercial, security, operations, finance and legal expertise enter where the capability demands them.

The case on the table

Consider a fictional B2B onboarding product. Customers upload supplier documents, and reviewers copy key fields into a structured risk form.

The team wants document extraction: identify the supplier name, registration number, dates and selected clauses, then show them for human confirmation.

No outcome or saving is assumed. The example starts before a pilot, when the team has needs and constraints but not a trustworthy performance history.

Five options are plausible:

1. Build extraction models and the supporting pipeline.
2. Buy a specialist document service through an API.
3. Configure an existing platform already licensed by the company.
4. Reuse an internal extraction capability owned by another team.
5. Defer automation and improve the manual review flow.

The fifth option matters. “Not yet” can be the responsible answer when evidence is thin or an exit would be expensive.

Write the capability without naming a solution

If the requirement says “integrate Vendor X”, the decision has already been smuggled into the brief.

Write the capability as an outcome with boundaries:

Reviewers need proposed values from supported supplier documents, linked to their source, so they can verify each value before it enters the risk record.

Then add constraints that are real rather than aspirational:

• documents may contain confidential and personal data;
• every extracted value needs visible provenance;
• a reviewer must confirm or correct it;
• unsupported formats need a safe manual path;
• customers need predictable processing and deletion;
• the first release supports a named set of fields and languages.

This prevents “AI extraction” from becoming an unbounded promise. It also gives system design a stable behaviour to support.

Ask whether the capability differentiates the product

Teams use “strategic” to mean important. Payroll is important; running a payroll engine may still not differentiate a product.

Use harder questions:

• Does better performance on this capability change why a customer chooses us?
• Will we need unusual behaviour that suppliers cannot support?
• Does the capability create proprietary learning that compounds?
• Would supplier constraints block our product strategy?
• Is the capability a gateway to a distinctive future, or supporting machinery?

For the onboarding product, trustworthy review may differentiate it. Owning low-level optical character recognition probably does not.

That suggests a split: retain ownership of field definitions, review experience, provenance, feedback and decision rules; source commodity extraction where evidence supports it.

The boundary is more useful than a blanket “buy AI” or “build our own”.

Put vetoes before preferences

A weighted score lets an attractive option compensate for a disqualifying weakness. A low privacy score can disappear beneath high marks for speed and features.

List veto conditions first. In this case, an option is out if it cannot:

• meet the organisation’s data-location and deletion obligations;
• return source locations for proposed values;
• keep a human confirmation step;
• export data and configuration in a usable form;
• operate within the agreed document size and latency boundary;
• provide enough evidence for security and operational review.

These are not all universal requirements. They belong to this capability and organisation.

A veto should be explicit and owned. “Security will not like it” is not a veto. “The service retains submitted documents for training, which this use does not permit” can be one.

Compare options through evidence questions

After vetoes, use a comparison that exposes uncertainty rather than burying it.

Decision lens	Build	Buy	Configure	Reuse	Defer
Time to learn	What is the smallest credible prototype?	Can a bounded trial use representative documents?	Which limits appear before custom code?	Is the internal service ready for this load and domain?	Can workflow changes reveal the real bottleneck?
Differentiation	Which owned layer improves with use?	Which supplier constraint reaches the customer?	Can configuration express the product promise?	Will another team’s roadmap cap our strategy?	What strategic learning waits?
Ownership	Which models, pipelines and controls become ours?	Which integration and supplier-management work remains ours?	Who maintains rules and upgrades?	Who supports failures across team boundaries?	Which manual cost and risk remain?
Exit	Can another implementation replace the component?	Can data, rules and evidence leave the supplier?	Are configurations portable or proprietary?	What happens if the internal owner withdraws support?	What signal will reopen the choice?

The table is a question set, not a scoring machine. The quality of evidence should remain visible in every answer.

The GOV.UK Service Manual advises its public-service teams to understand user needs, constraints, total cost and the ability to change technology.

Its off-the-shelf guidance also requires teams to test options and account for adaptation inside the whole service. These are useful decision prompts, not universal procurement rules.

Count the ownership burden, not only the invoice

Purchase price is rarely the total cost of a capability. Internal labour is not free, and vendor integration is not finished when the API responds once.

For each surviving option, map the work over its likely life:

Change work

• discovery, evaluation and contracting;
• integration, migration and configuration;
• product design for confidence, correction and failure;
• security, privacy and accessibility review;
• training, documentation and customer communication.

Run work

• monitoring, incident response and support;
• quality evaluation across changing document mixes;
• supplier or internal-owner management;
• upgrades, deprecations and regression tests;
• cost controls, capacity and misuse handling.

Exit work

• data and configuration export;
• replacement integration;
• parallel running and customer migration;
• deletion verification;
• loss of supplier-specific features or trained behaviour.

Do not force uncertain work into an exact five-year figure. Use ranges, name the assumptions and show which variable dominates the decision.

An API that looks cheaper per page may still be costly if reviewers cannot see provenance and manual rework rises. A built system may look cheaper if model maintenance is conveniently omitted.

Demand an exit that can be rehearsed

“We can switch vendors” is not an exit plan. An exit is credible only when the team can describe the artefacts, interfaces, time and product degradation involved.

For the extraction capability, ask:

• Are original documents stored independently from the supplier?
• Can extracted values, source locations and reviewer corrections be exported?
• Is the supplier hidden behind an interface we control?
• Which product behaviour depends on proprietary fields or confidence scores?
• Can the manual review path carry traffic during replacement?
• How will the team verify deletion at the old supplier?

Some architectural separation is worthwhile. Total abstraction is not. Building a universal adapter for hypothetical suppliers can cost more than a future migration.

Choose the seams that protect valuable product behaviour: document submission, extraction result, provenance, review outcome and audit record.

This is where understanding data platforms helps a PM challenge storage, lineage and portability assumptions.

The decision: buy a bounded component, own the judgement

In the hypothetical case, the team does not select a vendor yet. It chooses a sourcing direction and a test.

The decision is to trial specialist services for document-to-candidate extraction while keeping review, field definitions, provenance display and confirmed data in the product’s own boundary.

The decision excludes custom model development in the first phase. It also excludes a full workflow suite that would replace the product’s distinctive review experience.

Why not reuse the internal service? Its owner cannot yet commit to the required data boundary or support path. That may change, so reuse remains a future option rather than a rejected technology.

Why not defer? In this fictional case, observed manual review shows a recurring task worth investigating. The team will still improve that path because automation will fail on some documents.

The next step is a time-boxed trial across a deliberately varied, authorised document set. It tests field support, provenance, correction effort, latency, failure handling and export.

No supplier advances unless it passes the vetoes. No production commitment follows automatically from a promising demo.

Make the decision reversible in product terms

Technical substitution is only one part of reversibility. Customers may build habits and processes around supplier-specific behaviour.

Keep the first product promise modest:

• extracted values are suggestions, not decisions;
• the supported fields and document types are explicit;
• every value has a source or is marked unsupported;
• manual completion remains first-class;
• customers do not configure rules that cannot be exported;
• supplier identity is not used as a selling point.

These choices preserve room to learn. They also stop a sourcing experiment from quietly becoming a permanent product contract.

Record what would change the answer

Build, buy, configure, reuse and defer are decisions for a context, not identities for a company.

Review the choice when:

• extraction quality blocks an important customer segment;
• volume or unit cost crosses an agreed range;
• supplier terms or technical limits change;
• the capability becomes central to differentiation;
• an internal platform becomes credible;
• the exit test fails;
• new regulation or customer commitments alter the constraints.

The review should sit beside portfolio optimisation. Capabilities compete for investment and operating attention, not only launch capacity.

A good sourcing decision does not predict the next five years. It makes today’s trade-offs legible, protects the distinctive parts of the product and leaves a route out.

If the final slide only says “build” or “buy”, the team has skipped the hard part. The useful answer says what is owned, what is sourced, what is deferred and which evidence can still overturn the choice.

Sources

• GOV.UK: Choosing technology, an introduction
• GOV.UK: Commercial off-the-shelf products and services
• GOV.UK Service Standard, point 11: Choose the right tools and technology
• GOV.UK: Define your purchasing strategy

Read next

• Crafting a Winning Product Strategy
• From Theory to Practice: System Design
• From Strategy to Action: Portfolio Optimisation
• Understanding Data Platforms for Non-Technical PMs