How do you decide whether to build or buy a capability, and what makes the decision reversible?

What is being tested

Whether you decide on strategy rather than on capability, and whether you preserve the option to change your mind.

The primary criterion

Build what differentiates. Buy what does not.

The common error is deciding on capability — "we could build that" — rather than on strategy. Of course you could build an authentication system. The question is whether the engineering capacity spent doing it is better spent on the thing customers choose you for.

Engineering time spent building a commodity capability badly is the largest waste visible on most capability maps.

The secondary criteria

• Total cost over three to five years, including the run effort that appears on no invoice.
• Time to value. Buying is usually months faster, and those months have real value.
• Fit. Every product requires configuration or process change. A poor fit means heavy customisation, which erodes the reason for buying.
• Integration effort, consistently underestimated and sometimes larger than the build.
• Data. Where does it live, can you get it out, does the location satisfy residency obligations?

What makes the decision reversible

This is the part usually skipped, and it is what turns a one-way door into a two-way one:

1. An abstraction at the boundary. Your code speaks your domain's language; a thin adapter translates to the vendor's. Nothing outside that adapter knows the vendor exists. This is an anti-corruption layer, and it is one of the few speculative abstractions that reliably pays off, because vendors are eventually replaced.

2. Data portability, verified. Not "they say there is an export" — test it. Can you get your data out, in a usable form, at volume, and is it complete?

3. No business logic in the vendor's configuration. Rules encoded in a vendor's workflow engine cannot be migrated and will have to be rebuilt from scratch, which is where these migrations actually fail.

4. Standard interfaces where available, so a replacement speaks the same protocol.

The compromises worth knowing

Build on a platform — use a service for the undifferentiated substrate (payments, identity, messaging) and build the domain logic yourself. This is the right answer more often than either extreme.

Buy now, build later — buy to reach the market, replace when scale or differentiation justifies it. Entirely legitimate, provided the abstraction that makes replacement possible is built at the start rather than promised for later.

What a strong answer adds

That exit cost is a negotiating position. A vendor knows how expensive you would find leaving, and prices renewals accordingly. The abstraction and the verified export are not only engineering insurance; they are commercial leverage, and they must exist before the renewal rather than after it.