Running the Wrong Version of Your Business? The Hidden Cost of Backward Compatibility
From the engineering principle that explains structural rot to the surgical diagnosis that reverses it, here's how to stop running your fifth-stage business on first-version code.
If this made you feel seen, challenged, or called you’re not alone. Lights On is for those who crave more than noise, trends, and surface takes. Your presence here means something. Subscribe and stay with the signal.
Backward Compatibility: Why Growing Businesses Break Under Their Own Rules
The stage changes. The operating system does not. Here is the engineering idea that explains why, and the discipline that reverses it.
In software, backward compatibility is a promise: a new version of a system will still honor the assumptions the old one made, so nothing built on top of it breaks. It sounds like a virtue, and mostly it is. It is also, quietly, one of the most expensive commitments an engineering team can make, because every version afterward has to keep carrying code written for a system that no longer exists. The interface stays familiar. The internals rot. Eventually the system is not really running on its current version at all. It is running on the accumulated weight of every version it promised never to break.
A growing business makes the same promise, usually without meaning to, and pays the same tax.
The first employee. The first manager. The first million in revenue. Each is a version change, a new set of constraints the business now runs under. And at each one, the founder faces a choice that never feels like a choice: rewrite the assumptions for the system that now exists, or keep the interface the same and let the old logic keep running underneath, quietly, forever. Almost everyone picks the second, because it is invisible and free in the moment. That is exactly what makes it expensive later.
Why nobody migrates
This is not a discipline problem. It is a structural one, and it is not rare: McKinsey’s April 2025 research finds that 78% of companies that successfully build a product and reach product-market fit still fail to scale, not because the product stopped working, but because the operating model underneath it was never rebuilt for what the company had already become. McKinsey’s own phrase for it: what got you here will not get you there.
The reason is an asymmetry between patching and rewriting. A patch is locally rational. Approving one more decision yourself, keeping one more meeting on the old cadence, running the new market through the old playbook, each solves a real, immediate problem, and the person who does it can point to the fix. The cost is deferred and diffuse: a business that is slightly harder to run than it should be, in a way no single decision seems responsible for.
A rewrite is the reverse. Migrating to a new operating model, new decision rights, new meeting structure, new go-to-market logic for a market that is genuinely different now, is systemically valuable and locally expensive. It costs time today, risks breaking something that currently works, and whoever proposes it owns that risk alone while the benefit lands on everyone. So it does not happen, not because founders are lazy, but because the incentives point the wrong way at exactly the moment the business needs them pointed the right way.
The result is a company running its fifth version on first-version code, and calling the friction that produces “just how things are around here.”
What the debt looks like from inside
The sequence is almost always the same. Revenue triples. The org chart grows two layers of management. And underneath both numbers, the same person is still the approval bottleneck for nearly every meaningful decision, not because anyone chose that, but because it was never anyone’s job to notice the interface had not changed since the five-person version. New managers get hired and then quietly bypassed, because the fastest path to a decision still runs through the founder, and speed always wins in the moment, even while it is borrowing against the future.
The business is not undersized for its revenue. It is running the wrong version of itself.
The fix is never hiring more people or adding approval steps, that is just more compatibility code stacked on the old core. It is a deliberate migration: naming, out loud, which decisions the founder still needs to touch and which ones the org chart already implies someone else owns, then routing decisions through the new structure until defaulting back to the founder stops being the path of least resistance. That is not a one-time conversation. It is a version cutover, painful for a few weeks, because old habits do not update on command, and cheaper than every week after.
The test that tells you which version you are running
Not every old habit is debt. Some of what got you here is load-bearing and should scale untouched, a hiring bar, a quality standard, a way of talking to customers. So the useful question is never the abstract what should I stop doing. It is sharper than that, and it is the only one that actually sorts signal from noise: Does this decision still assume the business it was built for?
A process built to prevent a mistake you are still exposed to earns its keep at any size. A process built for a five-person team’s visibility, still running unexamined at fifty, is not discipline, it is legacy code nobody scheduled time to refactor. The distinction is never obvious from outside the moment, which is exactly why it has to be asked on a schedule instead of left to surface on its own. Debt does not announce itself. It just quietly becomes the interface everyone assumes is permanent. A surgical diagnosis is the starter kit. Everything else is guesswork.
And it is the hardest audit to run on your own system, because you wrote the original code. You are the person least able to see which parts are still load-bearing and which parts you have simply gotten used to stepping around. That is not a knock on judgment; it is what reading your own architecture from the inside always looks like.
The window, and what closes it
Every transition opens a short stretch where the new version could still be written cleanly, before the workaround becomes the culture, before “that is just how we do it here” hardens into an answer nobody remembers the question to. That window is not long, and it does not reopen on its own. It closes the moment enough of the business has been built on top of the old assumptions to make touching them feel dangerous.
Miss it, and the constraint you eventually hit will not be the market. It will be a version of the business nobody chose to keep running, and a founder still debugging problems that were already solved, one stage ago, in a system everyone agreed a long time ago to stop updating.
The cheapest place to start is almost always the same: one decision still routing through you that the org chart already assumes someone else owns. It is rarely the one founders expect, and it is rarely visible from the inside , which is exactly why you need someone who did not write the code to point it out. Find it. Name it. Route around it. That is not delegation. That is version control. And it is the only upgrade that actually matters.
Related article:
