Build vs Buy When Building Just Got Cheap.

The column that fell was never the expensive one

The reason build-versus-buy resisted a generation of tooling improvements is that the decision was never dominated by the cost of writing code. It was dominated by everything that happens after: the upgrade you did not plan, the security advisory on a transitive dependency, the quarter where the one person who understood the module left, the integration that has to be rewritten because an upstream API changed. Writing was the visible line because it was the one you scheduled. It was not the big line.

So when a tool cuts authoring cost by eighty percent, the honest effect on the total is smaller than the feeling it produces, and the feeling is what is currently driving decisions. The build case gets rewritten around the demo, which is real, and quietly keeps the old assumptions about everything downstream of the demo, which are now worse rather than unchanged.

Vibe coding removed the signal that said "not done"

The useful thing about a hand-built prototype was that it looked like a prototype. Rough edges were information. A reviewer could tell at a glance how far from production it sat, and that glance did real work in a build-versus-buy conversation, because it stopped anyone mistaking a proof of concept for evidence about total cost.

Generated code arrives formatted, commented and plausible at the stage where the old artefact looked obviously unfinished. That is a genuine improvement in one sense and the removal of a signal in another. The demo is not making a false claim about what it does; it is saying nothing at all about what it will cost, and it is now saying nothing while looking confident. If you want the practitioner version of where this holds and where it breaks, with real numbers, that is the vibe coding experiment rather than this page.

AI slop is a maintenance-column story

Slop is plausible, voluminous, unreviewed output. In a codebase it is the pull request that passes CI, reads well, and encodes an assumption nobody checked. Treated as a quality complaint it sounds like taste. Treated as a cost line it is precise: it moves the maintenance column upward at exactly the moment the authoring column falls, which is the worst possible timing for a decision that trades one against the other.

The mechanism is a shift in what is scarce. Authoring used to be the bottleneck, so review capacity was roughly sufficient by accident. Now a team can produce far more than it can absorb, and the deficit does not show up as a failed build. It shows up two years later as a module that works, that nobody has a mental model of, and that therefore cannot be changed cheaply or safely by anyone. That is the definition of an expensive asset. The debt mechanics of this, and how to measure the debt, are covered on technical debt in the AI era.

The practical consequence for a build case is one line: if the case assumes AI-accelerated authoring, it must also carry the review load that authoring creates. A model with the speedup and without the review cost is not optimistic, it is incomplete.

The seat-pricing argument, used honestly

Per-seat enterprise pricing rests on an assumption worth stating plainly: that value scales with the number of humans doing work inside the tool. Agents weaken that link. The work still happens, the seat count does not rise with it, and in some workflows it falls. This is a real structural pressure, and the visible response is that major suite vendors have been adding consumption-priced agent products beside their seat-priced suites rather than simply raising seat prices. Salesforce's Agentforce is the most-discussed example, and we cover the skills market around it in the Agentforce certification guide.

What does not follow is the conclusion most often drawn from it. "Their pricing power is weakening, therefore we should build it ourselves" compares our build at generation cost against their product at list price. Two errors, pointing the same way. If seats are mispriced for the agent era, the correct first move is to renegotiate against that fact, which is cheap and reversible. Building is neither.

There is also a quieter asymmetry. When a vendor's product ages badly, you switch, and the cost of switching is a number you can demand up front. When your own build ages badly, there is nobody to switch to. You are the vendor, and the migration is yours to fund. Pricing the exit from the buy option, in weeks and euros, is the single most useful thing most build cases are missing — and it is the number the vendor premium was actually purchasing.

The four questions

Who patches it in year three? Require a name, not a team. Teams reorganise; the question is whether a specific person will hold the model of this system when the person who generated it has moved on. If the honest answer is "nobody yet", that is the cost, and it belongs in the model rather than in the risk register.

Is this a differentiator or a commodity? Flexibility costs money and is only worth buying where you actually compete. Be flexible in the differentiators and ruthlessly standard everywhere else. A build justified by "we'd have full control" over something no customer will ever notice is paying for optionality with no option value.

What is the review load, not the authoring load? Estimate the build in reviewer-hours by people who will still be there next year. That number moved far less than the authoring estimate, and it is the one that predicts whether the thing gets owned or merely gets shipped.

What does exit cost, in weeks and euros? Ask it of the buy option, get it in writing, and then ask it of the build option too, where the answer is usually worse and almost never written down.

Adjacent reading: one-way doors for AI decisions on which choices deserve this scrutiny at all, and vendor capture risk on what happens when the exit number is never asked for.