Why "We'll Figure It Out As We Grow" Is the Most Expensive Plan a Business Can Have

"We'll figure that out once we're bigger" is one of the most common, most reasonable-sounding decisions a growing business makes — about documentation, about process, about the systems underneath the work. It feels like discipline: don't over-engineer for a size you haven't reached yet. Looked at over a longer horizon, it's frequently the more expensive choice, not the cheaper one, because the deferred problem doesn't wait patiently — it quietly multiplies while nobody's looking at it.

What makes this decision so easy to keep making is that it's genuinely correct the first several times it gets made. The mistake isn't in deferring once — it's in never revisiting the decision as the business's circumstances change underneath it, which turns a reasonable early call into a stale default nobody ever consciously re-examines.

Why deferring feels like the responsible choice

Building process early feels like spending time on overhead instead of growth. At a small size, that tradeoff genuinely looks correct — which is exactly what makes it so easy to keep deferring past the point where it's still true.

At an early stage, time spent on formal process really does compete directly with time spent on growth, and growth usually wins that argument correctly. The problem isn't the decision at that specific size — it's that the same decision keeps getting re-made by default, past the point where the business has grown enough that the informal version is now costing more than it's saving. Nobody ever explicitly decides to keep deferring; the original decision just never gets revisited, and inertia does the rest.

What actually happens while the decision gets deferred

Every month something stays informal is another month of a workaround compounding — a slightly different version of the same fix, applied slightly differently by whoever happened to handle it that day.

While a process stays undocumented and informal, it doesn't stay still — it drifts. Different people handle the same situation slightly differently, each variation becomes its own small inconsistency, and by the time the business is "big enough to justify" fixing it properly, there isn't one process to formalize. There are several slightly different versions that all have to be reconciled first, each one defended by whoever's been using it, none of them clearly more correct than the others.

A concrete picture of what this drift actually looks like

What started as "how we handle a refund request" becomes, over two years and three different people handling it, three subtly different unwritten policies — and nobody notices until a customer gets two different answers on two different calls.

Picture a business that never formally documented its refund policy, relying instead on "we just use good judgment." Over two years, three different people have handled refund requests, each developing their own slightly different sense of what counts as reasonable. A customer who calls twice, speaking with two different team members, gets two subtly different answers — not because anyone acted in bad faith, but because three unwritten, slightly divergent versions of the same policy have been quietly running in parallel the whole time, invisible until a customer happens to notice the inconsistency and asks about it directly.

Why fixing it later costs more than fixing it early would have

Formalizing a process that's already drifted into three different versions costs more than building the first version would have — because now there's a reconciliation problem on top of the original design problem.

This is the part that makes deferring expensive rather than free: fixing a process that's already splintered into several informal variations requires reconciling those variations before a clean version can even be built, which is a strictly harder and more expensive problem than designing the process once, early, before the drift had time to happen. The reconciliation step alone — figuring out which of three competing informal practices should become the official one, and getting everyone who's attached to their own version to accept the change — often takes longer than writing the original policy would have.

Why this is hard to see coming in advance

At the moment a workaround is first improvised, nobody can tell whether it's a one-time exception or the first instance of a pattern that's about to repeat for years.

Part of why this trap is so persistent is that the first instance of an informal workaround looks exactly like a reasonable, one-off judgment call — because it often is one. There's no obvious signal, in that first moment, that this particular workaround is about to become a recurring pattern rather than a genuine exception. The only way to tell the difference is noticing, in hindsight, that the same kind of situation has come up multiple times and been handled slightly differently each time — which requires someone to actually be tracking that pattern, rather than treating each instance as its own isolated judgment call.

What this means in practice

The decision isn't "build everything formally from day one." It's noticing the specific moment a workaround has been repeated enough times that the next repetition is costing more than fixing it once would.

None of this argues for over-building structure before a business needs it. It argues for noticing when a specific informal workaround has already been repeated often enough that the next repetition costs more than building the real version would — and treating that moment, whenever it arrives, as the actual trigger, instead of an arbitrary future size that keeps getting pushed back every time someone raises the question of whether now might finally be the moment to deal with it properly.