The Real Cost of "We'll Build It Later"

Every growing business defers things. It is not a failure of discipline; it is how anything ships. The list of things that would be nice is always longer than the time available, and choosing what not to do is most of what running a company consists of.

The trouble is that deferral is usually costed as though the work simply moves. Do it now or do it in six months — same work, later date. That is almost never true, and understanding why makes the decision better rather than merely guiltier.

What actually accumulates

The deferred work does not sit still. Three things grow around it.

Workarounds. Every day the gap exists, somebody invents a way around it: a spreadsheet, a naming convention, a manual step, a rule they remember. These become load-bearing. When the real thing is finally built, the workarounds must be found and unwound, and they are undocumented by nature.

Data shaped by the absence. This is the expensive one. If there is no field for something, the information goes in a notes field, or into a repurposed field that means something else. Six months later there are thousands of records where a column called "reference" contains three different kinds of value depending on when it was written. The eventual fix is not building a feature; it is building a feature plus a migration plus a period where both conventions exist.

Decisions that assumed the gap was permanent. People plan around what exists. Processes get designed with the missing piece routed around. Those designs get taught to new staff as how things are done, and they outlive the gap by years.

The work you deferred is unchanged. Everything around it is not.

The compounding is not linear

A month of deferral is close to free. Six months is meaningfully more than six times as expensive. The reason is that workarounds have to be discovered before they can be removed, and discovery scales with how many people have invented their own.

This is why "we'll do it later" is a much better decision at small scale than large. Two people sharing a workaround can both stop on the same afternoon. Twenty people with four variations of it is a project.

Two specific gaps that get much worse with time

Some deferrals are ordinary. A couple are unusually punitive, and it is worth knowing which ones.

Not handling duplicate operations. If a system that creates records, sends messages, or charges money has no protection against doing the same thing twice, the fix later is not just a code change. It is a code change plus reconciling however many duplicates accumulated in the meantime. The property to build in early is idempotency — repeated identical requests having "the same effect... as the effect for a single such request" [1] — and it is dramatically cheaper before the duplicates exist than after.

Not tracking who authorised a connection. Integrations run on delegated grants, letting an application "obtain limited access to an HTTP service... on behalf of a resource owner" [2]. If nobody records which person approved which connection and why, that information does not become available later — it becomes permanently unavailable, because the people who knew leave. This is one of the few gaps that cannot be closed retrospectively at any price.

Both share a shape: the deferred work is small, and the deferred record is the thing that becomes irrecoverable.

When deferring is genuinely right

Most of the time, and it is worth saying clearly, because the argument above can be read as a case for building everything up front. It is not.

Defer when you do not yet know the rule. Building a feature before you understand the process it encodes produces a wrong feature that is then expensive to change, and which people work around anyway. A manual process you understand beats an automated one you guessed at.

Defer when the volume does not justify it. A manual step performed twice a month is fine forever. Not everything that could be systematised should be.

Defer when the alternative is capturing data you have no use for. Building a field because it might be needed is the same instinct as collecting data speculatively "in case it is useful later" [3], and it produces a system that is harder to use in exchange for nothing.

The deferral that is really a decision

Some things get described as deferred when they have actually been decided against, and the mislabelling causes its own damage.

"We'll do it later" is comfortable because it avoids an argument. Nobody has to say no, nobody has to justify a priority, and the person who wanted it leaves the conversation with something that sounds like a yes. The cost arrives months afterwards, when they discover it was never going to happen and conclude — reasonably — that they were managed rather than answered.

The same ambiguity affects planning. An item that is genuinely deferred should influence how the surrounding work is built, because the gap is temporary and worth designing around. An item that has been declined should not: building accommodations for something that will never arrive is pure waste.

So it is worth being blunt about which one a thing is. "Not now, and here is the condition that would change it" is a deferral. "Not unless something significant changes, and here is what that would be" is a decline. Both are respectable answers. Only one of them should shape what you build next.

How to defer well

The difference between healthy deferral and accumulating trouble is almost entirely about what you write down.

Record the decision and the reason, somewhere findable. Not a ticket in a backlog nobody reads — a note attached to the thing it concerns. Six months later the question will be "why does this work like this", and an answer saves an afternoon of archaeology.

Record the workaround explicitly, as a workaround. The most damaging thing about an undocumented workaround is not that it exists, but that it becomes indistinguishable from a design decision.

Name a trigger rather than a date. "When we pass 500 customers" or "the next time this costs someone a day" is more useful than "Q4", because dates get moved and conditions get met.

And prefer deferring the feature over deferring the record. Doing the work by hand is cheap; not writing down what happened is what becomes unaffordable.