Skip to content
Richard Cooper
Go back

The last responsible moment

There’s a particular kind of architect who decides everything up front. The database, the message broker, the folder layout, the auth scheme — all pinned before a line of business logic exists, on the theory that a plan is what separates engineering from flailing. And there’s the opposite kind, who decides nothing, calls it agility, and leaves a trail of half-built options that never resolve into a system. Both are getting the timing of decisions wrong, and the idea that sits between them has a name.

Decide when not deciding costs you something

The last responsible moment comes from Lean, by way of Mary and Tom Poppendieck’s Lean Software Development, who borrowed it from the Lean Construction Institute. The definition worth memorising is theirs: the last responsible moment is the point at which failing to make a decision eliminates an important alternative. Wait past it and the choice gets made for you — by circumstance, by something you’ve already built on top, by a door quietly closing while you weren’t looking.

The word that does the work is responsible, and it’s usually the one people drop. This is not the last possible moment, which is just procrastination with a Lean sticker on it. It’s the last moment you can wait and still choose freely. Before it, deciding early throws away information you haven’t gathered yet. After it, you’re not choosing at all — you’re ratifying whatever the delay decided for you.

Why waiting is often the responsible thing

The instinct to decide early feels like diligence, but it usually means committing at the point of maximum ignorance. You know least about a system on day one: least about the real load, the real edge cases, the shape the domain actually wants to take, which of your assumptions were fantasy. Every week you build, you learn something that would have changed an early call.

So deferring isn’t laziness — it’s refusing to spend certainty you don’t have yet. This is the same instinct behind YAGNI, and behind resisting premature abstraction: the abstraction you’d have written on Monday is worse than the one you’ll write on Friday once three real call sites have shown you where the seams belong. Committing early doesn’t remove the risk. It just moves the decision to the moment you understood the problem least. It’s the same reason it pays to treat a design as something that evolves as the evidence arrives rather than something to get right once and freeze — the last responsible moment is that principle applied to a single decision.

Reversibility buys you time

Here’s where the last responsible moment connects to something I’ve written about before. How long you can responsibly wait is mostly a function of how reversible the decision is. A two-way door has a last responsible moment that’s very late — you can walk through, learn, and come back — so there’s rarely a reason to agonise early. A one-way door’s last responsible moment arrives sooner and hits harder, because once you’re through, the alternatives are gone.

Which means the two ideas compound. A lot of good architecture is deliberately turning one-way doors into two-way ones — a boundary you own, expand/contract migrations, a feature flag — and every time you do, you push the last responsible moment further out. You’re not just making the decision reversible; you’re buying yourself the right to defer it until you actually know something. Design for reversibility and “decide later” stops being a gamble and becomes a strategy.

A worked example: deferring the spend

Not every deferred decision is a design choice — sometimes it’s just money. We recently picked a document-generation tool whose free, self-hosted tier does very nearly everything we need: authors build templates in a visual studio, preview them live, drop into raw HTML or Markdown when they have to, lean on a bit of AI assistance, and we wire in our own authentication, storage and formatters over its REST API. That’s enough to author real templates and demo the whole flow to stakeholders today, at no cost.

The one thing the free tier won’t do is embed that authoring studio inside our own admin UI — for that you need a paid licence, a few thousand euros a year. And putting the editor directly in the product is genuinely on the roadmap, so the reflex is to buy the licence now because we “know we’ll need it”.

But using the free standalone studio forecloses nothing — same templates, same APIs, same everything — so we let authors use it today and wrote down a decision instead: buy the embed licence only when we’re actually ready to build the embed. The embedded-editor goal still stands; the spend defers to the last responsible moment — the point where embedding is real work in front of us, not the point where it first merely felt inevitable. The free tier keeps the door two-way, so waiting costs us nothing and buys optionality — the roadmap could shift, requirements could change, a better option could appear — and the trigger is named: the licence gets bought when the embed work is scheduled, not a day before.

The moment you have to catch

The failure mode nobody warns you about isn’t deciding too early. It’s missing the moment entirely. “Last responsible moment” quietly assumes you’ll notice when it arrives — and moments don’t send calendar invites. The option to keep the datastore swappable expires the first time a query leans on a database-specific feature. The option to split a service cheaply expires once two teams are elbow-deep in the same module. The window closes silently, and you find out months later when someone says “we can’t easily change that now.”

So deferring a decision is not the same as forgetting it. A deferred decision is one you’re actively watching, with a trigger you’ve named in advance: we choose the messaging approach the moment we need the second consumer; we pick the caching strategy when p99 crosses this number. Without a trigger, “we’ll decide later” is just “we’ll be surprised later.” This is also why deferral has a carrying cost — an open decision is a bit of uncertainty everything downstream has to tiptoe around, and holding too many open at once is its own kind of chaos. The skill isn’t deferring everything. It’s knowing which few decisions are worth keeping open, and what will tell you the moment has come.

Some moments are earlier than they look

The honest complication: not every last responsible moment is late. Some decisions have long lead times, and for those the responsible moment to decide is now, even though the consequence lands much later. If a choice needs a procurement cycle, a data migration, a hiring plan, or six months of gradual rollout, then “decide when we hit the wall” means deciding far too late — the wall arrives before the decision can take effect.

That’s the part that keeps this from being a licence to dither. The last responsible moment for a call with a long tail is pulled forward by exactly that tail. Working out where it actually falls means being honest about lead time, not just reversibility — and it’s precisely the calls with long lead times and low reversibility that deserve the early scrutiny, while everything else waits.

The actual discipline

Put the two failures side by side and the rule falls out. Deciding too early spends certainty you don’t have. Deciding too late lets circumstance choose for you. The last responsible moment is the seam between them, and hitting it means doing three unglamorous things: knowing roughly where that moment is for each decision that matters, keeping the reversible ones open until then, and watching for the trigger that says now.

“It depends” was the honest answer to what to decide. This is the honest answer to when: not as early as it feels safe to, and not as late as you can get away with — but at the last moment you can still choose freely, and not a step past it.


Share this post:

Previous Post
The cost of premature abstraction
Next Post
Deployment coupling