The Cost of Cheap Building

Somewhere in your product there's a feature that took a quarter to build and has eleven users. It still gets security patches. It still appears in the onboarding flow, where new customers dutifully learn it before never touching it again. It still has to be checked every time anyone changes anything nearby. Nobody would build it today. Nobody will delete it either, because deleting it means migrations, an awkward email to the eleven, and a conversation with the person who championed it.

That feature is not an accident. It's a preview.

The cost of building has collapsed, and the celebration has mostly missed what the cost of building actually was. It was a price paid once, up front, and it was the smallest number on the invoice. The larger numbers arrive later; maintenance, support, security, documentation, the testing matrix, the onboarding surface, and the quiet obligation to route every future decision around the thing's existence. AI has slashed the first number and left the rest untouched. We didn't make building cheap. We made it cheap to acquire expensive things.

Anyone who has furnished a house on sale items knows this economy. The bargain is real, the clutter is also real, and the clutter is what you live with.

It would be a manageable problem if it were only a software problem. It isn't. Reports are now cheap, so executives commission more of them, and each unread deck teaches the organisation a little more firmly that documents are noise. Job specs are cheap, so roles get created on a whim and org charts grow appendixes that some future leader will spend a painful year removing. Strategy documents are cheapest of all, a plausible one costs an afternoon. Which means any leadership team can now hold six of them at once, each dilute enough to survive scrutiny because none was expensive enough to demand it.

Abundance can make accumulation look like progress.

From the inside, all of this looks like health. Output is up. The demos are frequent, the dashboards busy, the velocity charts pointed the right way. The tax is invisible precisely because it's distributed; a little more support burden here, a slightly longer decision there, a codebase or a calendar or an org chart that everyone privately finds heavier than it used to be and nobody can blame on any single addition. No line item says "sprawl". It just gets a little harder, each quarter, to do anything.

And the tax collectors are not who you'd expect, because the scarcest currencies were never money. Every shipped thing bids for your customers' attention, and attention spent finding the useful part of your product is attention you charged them, not value you gave them. One widely cited Pendo analysis found that around eighty per cent of software features are rarely or never used. Which means most product surfaces are, functionally, a search problem the customer didn't ask to solve. Every mediocre thing you ship also spends trust, and trust is the only budget that compounds against you silently. Customers rarely announce that a lacklustre feature lowered their opinion of you. They just believe your next announcement a little less.

There's an old defence against all of this, and it's worth taking seriously; ship it and let the market decide. Volume as strategy. It worked, sometimes, when shipping was hard because difficulty had already filtered the candidates, and the market was only ever asked to judge the survivors. Cheap building removes the filter and then triples the applicants. The market can still edit, but you're now asking your customers to do the quality control your own judgement declined to do, and they will do it by leaving.

Here's the asymmetry underneath the whole essay; starting has become free, and stopping has not. Stopping still costs everything it ever did; the migrations, the sunset plan, the sunk-cost grief, the champion's face. So the portfolio only ever grows, and it grows with things too cheap to have been questioned on the way in. Expensive mistakes at least used to teach. Cheap ones don't even get noticed; they accumulate.

We should say where this argument could fail, because a case that names no losing condition isn't a case. If AI eventually makes ownership as cheap as creation — self-maintaining software, self-updating documents, organisations that reshape without pain — then the tax shrinks and this essay ages badly. Some of it, though, no technology can discount, because attention and trust live in your customers, not your codebase. That part is a bet we're comfortable staking.

The response isn't to build slowly for the sake of it. Slow is not a virtue; it was just the old filter's side effect. The response is to re-price the decision. Treat shipping as adopting, not delivering; you're not finishing something, you're taking permanent custody of it. The launch is the cheap day; what follows is years of maintenance, support tickets, documentation to keep current, security to patch, and organisational complexity that quietly compounds around everything you own. Every feature you keep is a standing claim on your team's future attention. Ask the question the old difficulty used to ask for free; is this worth owning, at full cost, for years? And once a quarter, ask the harder one of everything already in flight:

Knowing what we know now, would we start this again?

Most organisations never ask, because nothing forces the pause anymore.

Nothing now dies of difficulty.

Worth Building · July 2026