Buy, build, or configure: a framework for the middle option

The build-or-buy question is usually posed as a binary, and the interesting answer is almost always in the middle: configure a platform you buy, and build only the part that is genuinely yours.

Start with what is actually distinctive

Write down the process you are trying to support, then mark each step as either something a competitor does identically or something that is genuinely particular to you.

Almost everything is the former. Invoicing, authentication, notifications, document storage, scheduling — these are solved, and solved better than you will solve them, by products that have had thousands of customers find their edge cases.

The parts that are genuinely yours are usually few and specific: a pricing rule nobody else has, a compliance workflow peculiar to your sector, an integration between two systems only you run together. That is the part worth building.

A framework for the middle option

1. 01Would a competitor recognise this process as the same as theirs? If yes, buy it.
2. 02Does a platform do eighty per cent of it out of the box? If yes, configure it and build the remaining twenty as an extension rather than a replacement.
3. 03Does the platform have an API that would let you build that twenty per cent without forking it? If not, that is a serious mark against it.
4. 04What does leaving cost? If the answer is unknown, find out before signing, not during the renewal.
5. 05Who maintains the configuration? Configured platforms still need an owner; "nobody" is how they rot.

Where buying goes wrong

Two failure modes, both avoidable. The first is buying a platform then customising it so heavily it can never be upgraded — you now own bespoke software with a licence fee attached. The second is buying several overlapping products that each hold part of the truth, which is how an organisation ends up reconciling by hand.

Where building goes wrong

Almost always by underestimating the second year. The build is budgeted; the maintenance, the security patching, the dependency updates and the person who understands it leaving are not. A useful discipline is to budget three years of ownership and compare that against the licence, rather than comparing the build cost against the first year's subscription.

If you take a single rule from this: buy the process, build the difference. Most disappointing systems are the result of doing exactly the opposite.