Build or Buy: Choosing a Digital Transformation Provider Without Outsourcing the Wrong Thing

Build or Buy: Choosing a Digital Transformation Provider Without Outsourcing the Wrong Thing

Before you compare providers, decide which parts of this work should sit outside your organisation at all. Getting that wrong can be costly because replacing a supplier may be easier than rebuilding an internal capability that has been lost.

Three questions can guide the decision for each capability, and the table below turns the answers into an initial verdict. Use it before requesting proposals, allowing enough time to discuss the evidence behind each answer.

A build-or-buy decision table

AY prepared this table for this guide, and it is set out here for you to use yourself. Answer three questions about the capability in question — not about the project:

Then read the verdict:

What you do with this: run the three questions over each capability in your scope separately, and expect different verdicts within one programme. A single decision applied to a whole transformation is the error this table exists to prevent.

Treat the verdicts as conditional guidance rather than rules. Alongside the three questions, weigh total cost, scale, security requirements, availability of the skill in your market, service quality, how much strategic control you need, dependency on one supplier, continuity if the arrangement ends, and whether knowledge transfers. Any of these can reverse a verdict, and the table does not price them for you.

The last row requires particular discipline. "Buy now, build deliberately" can drift into a permanent arrangement unless the intended build date, internal owner and handover scope are documented at signature. If you cannot name that person today, treat the arrangement as Buy for now rather than describing it as temporary.

Three capabilities to keep inside the organisation

Independently of the table, three decisions generally require clear internal ownership:

• Defining what a metric means. If a supplier alone owns the definition of your core figures, you may lose control over reporting consistency when changing providers.
• Owning the customer journey. The sequence a customer experiences is a product decision. Delivery can involve external parties, but accountability for the journey should remain internal.
• Accepting a control exception. Security and data protection exceptions are risk acceptances. They need a named person inside the organisation, in writing, with an expiry date.

Keeping these inside means holding the decision and the accountability, not necessarily performing every task with your own staff — external expertise can inform a metric definition that you still own and approve. What you do with this: check your current contracts against these three before renewing any of them. Where one of them has shifted outside, restoring internal ownership may be possible through clearer documentation, depending on the contract and timing.

What "cheaper in-house" usually leaves out

Comparing salary with a provider's day rate gives an incomplete view. Four build-side costs are also easy to overlook:

1. Coverage. One specialist may not provide a resilient capability. Leave, illness and resignation require a coverage plan, which may involve another employee or external support.
2. Tooling and environments. Licences, environments and monitoring are carried by a provider and become yours on the build side.
3. Time to competence. A hired specialist may need time to become productive in your context, and that ramp-up period is a real cost.
4. Retention in a scarce market. Where the skill is scarce, training can make the employee more marketable, and retention may add further cost.

What you do with this: when someone presents an in-house option, ask for these four lines specifically. The decision often survives them — continuous differentiating work generally should be built — but it should survive them explicitly rather than by omission.

What the contract has to say once you have bought

A buy verdict transfers work, not obligation. Four clauses decide whether that stays true in year two:

Who produces which evidence for which control. Cloud cybersecurity controls bind the subscriber alongside the provider, so an obligation does not move by contract. Write down who produces each piece of evidence after go-live — not who "bears responsibility" in general terms. This clarification can reduce the risk of a later dispute over evidence production.

What is handed over, in the acceptance criteria. Systems, data definitions, documentation and runbooks — listed, not implied. If handover is absent from the acceptance criteria, securing it later may become more difficult.

What exit looks like. Notice period, data export format, and who operates the system during the transition. Agreeing this at signature is generally easier than negotiating it during a separation.

Named people and committed time. The team in the pitch and the team in the contract should be the same people. Ask for names and a time commitment in writing.

What you do with this: take these four into your next contract review as a checklist. They are generally easier to agree before signature than to add afterwards.

Co-sourcing: the option that gets skipped

Build and buy are usually treated as the two available answers, and a third exists for the "continuous + table stakes + scarce" row: the provider operates while a named person inside your organisation works alongside them. That can run to a defined handover scope and date, or it can be a deliberate long-term arrangement — both are legitimate, provided the intent is chosen rather than drifted into.

This is not simply a lighter version of buying. It has specific requirements; without them, the arrangement may add meetings without transferring capability:

• A named internal person with allocated time, not an additional duty on an existing role.
• A written handover list — which procedures, which systems, which decisions — not "knowledge transfer".
• A date, and a review at half that date to check the transfer is actually happening.

What you do with this: if the intent is handover and you cannot meet all three conditions, choose Buy deliberately rather than co-sourcing nominally. An arrangement described as temporary but lacking measurable transfer may incur both provider costs and internal time without building the intended capability. A long-term co-source chosen on purpose is a different decision, and it should be priced and reviewed as one.

How the verdict changes what you ask for

The build-or-buy verdict changes the request you make, not just who fulfils it:

What you do with this: put the verdict in the first paragraph of your RFP. Providers price these four very differently, and a proposal written against the wrong one is not comparable with the others.

The adjacent decisions, and where they are made

• How do I evaluate and compare the companies themselves? The guide to choosing a transformation company.
• What am I buying, and what sets its price? The digital transformation services guide.
• Which of my existing systems do I keep, replace or retire? The digital modernization guide.
• Who decides what once the change lands? The digital operating model guide.
• How do I get this approved and funded internally? The transformation business case guide.

How AY works

AY can serve as an external provider, and an assessment should also identify which capabilities are better retained or built internally. Where an arrangement is meant to transfer a capability, the handover scope, the named internal recipient and the date belong in the engagement rather than in intent — and that applies to any provider, not only to us.

We do not promise a guaranteed outcome. Examples are in our work, and the scope is set out in enterprise digital transformation.

Next step

List the capabilities in your current scope and run the three questions over each one. Expect the verdicts to differ across the list — that variation is the point of doing it capability by capability rather than once for the programme.

If the list itself is unclear, because the scope is described as one project rather than a set of capabilities, that is the point at which involving an outside party becomes useful. Talk to us about whether an assessment fits your case and what it would cover — the scope and outputs of any assessment are agreed before it starts rather than assumed in advance.