There is a meeting that happens at the start of every significant programme, and almost nobody attends it with the attention it deserves. The decisions get made quickly — sometimes in the corridor outside the room, sometimes by the senior person who has somewhere to be, sometimes by default because nobody felt strongly enough to push back. Six months later, a different room is full of people trying to live with those decisions. Eighteen months later, a later review is underway — at considerable cost — to revisit them. The decisions did not get more important between the first meeting and the programme review. They got more expensive to change.
This is one of the cleanest patterns in technology programmes, and one of the least well-defended against. Every technical decision has a price. Made early — at the concept stage, when nothing has been committed and no other decision depends on it — the price is almost nothing. The same decision, made after design has hardened, costs more. Made during build, more again. Made after the system is in production, with traffic and users and data flowing through it, the cost can be larger than the value of the entire project up to that point. Most people understand this directionally. Almost nobody understands it quantitatively, which is why it keeps happening.
The numbers on the chart are approximations — the multipliers vary by industry and by how cleanly a system is built — but the shape is real and reliable. A decision worth a few minutes of conversation at concept costs perhaps an afternoon of redrawn diagrams in design. Push it into build and the same decision is a sprint, sometimes a quarter. Wait until production and it is no longer a technical decision; it is a programme with a steering committee, a change-control conversation, a vendor renegotiation, and an executive sponsor who would rather be doing anything else. None of the underlying engineering has changed. The price has, by three orders of magnitude.
The reason this matters in practice — beyond knowing it exists — is that almost every team behaves as if the curve were linear. They treat a decision in build as if it were twice as expensive as one in design, when in reality it is ten times. They treat a decision in production as expensive but manageable, when it is genuinely a different category of work altogether. The result is calm overconfidence in early meetings, where the cost of being wrong feels small because it is small, and panicked overcorrection in late meetings, where the cost is suddenly enormous and the room is full of people who cannot quite believe that the consequence of one decision could be this large.
Why the curve bends — four mechanisms
Knowing the shape is useful. Knowing why the shape is what it is, is what lets you use it. Four things compound to bend the cost curve upward, and each of them individually multiplies the cost of changing a decision later.
The first is the cleanest to explain and the most overlooked. Dependencies set around a decision the moment it is made. Every subsequent decision is taken in the light of the one before, assuming it. Change the early decision and every downstream one has to be revisited — most of them by people who do not know they need to revisit them. The cost is not the original decision. It is the cascade of small, silent assumptions made on top of it. A decision touched by twenty other decisions does not cost one unit to change; it costs twenty.
The second is the most visible. Artifacts have been built. Code has been written, infrastructure provisioned, runbooks documented, tests authored, training delivered, integrations wired. Each artifact represents work that has already happened. Changing the underlying decision means most of that work has to be redone, or thrown away, or carefully retrofitted. This is the cost most people see, because they can point at it — the deployed system, the trained team, the signed contract. It is also the smallest part of the real bill.
The third compounds the first two and is rarely discussed in technical terms. Organisational momentum settles around the decision. Vendors are selected and contracted. People are hired with skills matching the chosen direction. Planning forums have been told what is being built. Stakeholders have been given commitments. Senior leaders have stated the direction publicly. Reversing the decision is now not just a technical exercise; it is a political and contractual one, and the cost of that conversation is measured in reputation as much as money. The technical work might be the easy part by the time these conversations have to happen.
The fourth is the multiplier that compounds the others. Production cannot pause. Once a system is live — users on it, data in it, traffic flowing through it — every change has to be made around the live state. Migration, rollback, staged deployment, traffic management, dual-running, careful failure modes. None of these are technical impossibilities; all of them are an order of magnitude more expensive than the equivalent change made before go-live. A decision that would have been an afternoon in design might be a quarter in production, and a critical-path quarter at that.
The four mechanisms do not add together. They multiply. A decision in production is not four times worse than one in concept — it is dependencies times artifacts times momentum times production, all compounded. That is what the cost curve actually measures.
What to do with this in practice
The point of understanding the curve is not to be right about it afterwards. It is to use it in the moment, before the cost is already locked in. There are three habits that follow directly from taking the curve seriously, and each of them is worth a small piece of discomfort early to avoid a much larger piece of discomfort later.
The first is to identify which decisions are load-bearing as soon as possible. Not every decision sits on the curve in the same place. Some are cheap to change at any point — the colour of a button, the wording of an error message, the precise size of a virtual machine. Others are load-bearing — identity, data residency, the shape of the public interface, the operational model — and these are the ones where the curve is steepest. The first job of an architect in an early meeting is to flag, out loud and on the record, which decisions are which. Most rooms will not do this unprompted, because the load-bearing decisions feel abstract while the visible ones feel concrete. They are the wrong way round.
The second is to refuse to defer load-bearing decisions for comfort. When a meeting struggles with a hard decision, the easiest move is to defer it — "let's revisit this in the next phase" — because deferral feels productive. For most decisions, deferral is fine. For load-bearing ones, deferral is moving the same decision into a part of the curve where it costs ten times as much. The instinct to defer should be inverted: the harder a decision feels, the more likely it belongs at the cheap end of the curve, and the more important it is to make it now even if poorly. A merely-good decision made early almost always beats a perfect decision made late.
The third is to name the curve out loud in the room. The best use of this essay, frankly, is to be able to say — clearly, in a meeting where a load-bearing decision is being deferred — that this is a one-times decision now and a hundred-times decision in six months. People do not need to be persuaded of the principle. They need to be reminded that they already believe it, and they need someone in the room to say it. The cost curve is a piece of language as much as a piece of analysis. Once a team has learned to use it, the same decisions start happening earlier without anyone having to make a fuss.
The same idea can be said more simply
You can write the whole essay above as a single sentence, and it might be the most useful sentence to remember. A decision is cheap at concept, expensive at design, painful during build, and almost prohibitive in production — and the difference between the cheap version and the prohibitive one is often the same decision, made by the same people, six months apart.
That sentence is more useful than many frameworks because it is easy to recognise in the moment. It does not require the curve to be measured precisely; the orders-of-magnitude version is enough. It does not require every mechanism to be listed; the intuition that they compound is enough.
What it requires is the discipline to say it while the decision is still being made, and to mean it. That discipline is harder than it sounds, because the cheap end of the curve always feels like there is plenty of time, and the expensive end always feels like an unforeseeable surprise. They are the same decision. The curve only looks like a surprise from the wrong end of it.