Build versus buy: why the arithmetic changed

The build-versus-buy rule most companies still use was formed when building meant a team of six for nine months. Against that, renting was obviously right for anything that was not the core product. The rule was correct. Its inputs have changed.

What actually changed

Not the existence of AI coding tools — those are widely misunderstood as replacing engineers, which they do not. What changed is narrower and more consequential: a senior engineer who knows the domain now produces working software substantially faster than the same engineer did five years ago. The judgement, the architecture and the responsibility are unchanged; the typing, the boilerplate and the first draft are much cheaper.

That compresses the build side of the comparison in both money and time. A system that would have justified nine months and a team can now justify weeks and a specialist. Meanwhile the rent side has moved in the other direction: per-seat prices have risen, and the bundling of features you did not ask for has risen with them.

Where buying is still obviously right

• Commodity processes with a compliance burden — payroll, tax, accounting. You are buying somebody else's obligation to keep up with legislation, and that is worth real money.
• Anything where the vendor's scale is the product: email delivery, payments, mapping, identity.
• Small seat counts, where no arithmetic rescues a build.
• Processes you are about to change fundamentally. Do not build a system for a process you do not yet understand.

Where the answer has flipped

• Processes specific to how your company competes, forced into a generic platform's shape and losing something in the translation.
• Heavy integration with systems you already own, where most of the platform's value is being spent on getting data in and out of it.
• High seat counts on features a fraction of users touch.
• Anywhere the platform has started to dictate the process rather than support it — the clearest signal, and the hardest one to put in a spreadsheet.

The honest caveat

Faster building does not mean risk-free building. A custom system still needs maintenance, still needs someone who understands it, and still fails if it is built for a process nobody agreed on. What has changed is the size of the bet, not the existence of one. A smaller bet deserves a fresh look at questions that were closed years ago — and that is all this note is arguing.

How to decide without a project

Measure usage against licences, count what integration really costs, and put five years of rent next to one fixed-price quote. If rent still wins, you have saved yourself a migration. If it does not, you now have the number rather than the intuition.