Build or buy? Start with the exit rehearsal.

What will you own after launch?

A supplier can make a workflow look effortless in a demonstration. An internal developer can make the same workflow look inexpensive in a prototype. Neither presentation tells you who will fix it when an upstream system changes.

For an advice firm, our preferred build-or-buy comparison starts with the period after launch. List the work required to keep the capability useful, then decide who is best placed to own it.

That includes maintenance, access reviews, exception handling, staff training, data recovery and eventual replacement. Initial delivery cost matters. It is also the easiest cost to see.

Ask which parts of the workflow reflect the firm's genuine operating choices. A distinctive service process may justify internal control over a narrow component. Commodity functions with established suppliers may offer little benefit from rebuilding.

That does not require an all-or-nothing decision. The firm might buy the core application and build a small connection around a genuinely specific handoff. It might also discover that configuration achieves the same result with less maintenance.

Be suspicious of calling a process unique before documenting it. Unwritten exceptions can look like strategic differentiation when they are simply inconsistent practice. Standardising those exceptions may change the economics before any code is written.

The Government Service Manual approaches technology selection through the ability to change course and the total cost of ownership. It is guidance for government services, but the buying principle is portable: evaluate the future decisions a product permits as well as the functions it delivers today.

Put support in the comparison

For a build, identify who maintains it when the original developer leaves, how changes are tested and where the operational documentation lives. Include time for adapting to external changes, not just fixing your own defects.

For a purchase, ask how failures reach the supplier, what evidence the support team needs and which problems remain the firm's responsibility. A support contract is useful only if staff know how to invoke it and can work while waiting.

The FCA's outsourcing guidance makes clear that using third parties does not transfer away a firm's regulatory responsibility. The exact obligations depend on the arrangement and firm. A procurement scorecard is an operating aid, not a substitute for that assessment.

Rehearse leaving

Before committing, request a representative export and try to use it. Check that client identifiers, relationships, documents, action histories and timestamps remain understandable outside the application. A pile of files is not necessarily a usable business record.

Ask what happens to integrations and ongoing work during departure. Can unfinished actions be transferred? Can the firm explain historical decisions after access ends? What notice, assistance or fees apply?

Run the same thought experiment for an internal build. Could a different developer operate it? Are deployment steps repeatable? Can the data be recovered without the author explaining the schema over a call?

Decide on the whole obligation

Write a compact decision record covering the chosen option, rejected alternatives, maintenance owner and conditions that would trigger reconsideration. Keep assumptions visible, especially estimates of internal time and supplier support.

Then make the first commitment small enough to test those assumptions. A limited workflow with representative cases can reveal whether the proposed operating model holds up before the firm commits a wider client population.

Buying can reduce engineering work. Building can preserve control. Either can create dependence if nobody has planned for change.

The decision becomes more honest when the team can demonstrate two things: how the capability will work next Monday, and how the firm could replace it a year from Monday.