The team was excellent. They tuned for the wrong variable.
A manufacturing client spent a year and a full budget “modernising” an ERP and shipped nothing usable. The team was excellent. They just tuned for the wrong variable. They ran a startup playbook in a place startups do not live: a factory where a bad deploy stops a machine.
The blast radius of a startup bug is an annoyed user who refreshes and grumbles. The blast radius of an enterprise bug is a stopped line, a missed regulatory deadline, or a warehouse crew that cannot scan a pallet. The business pays, not the customer. That single difference inverts most of the advice that sounds wise in a startup context.
Two pieces of gospel that invert
“Rewrite it, the old code is garbage.” In a fifteen-year-old ERP, those ugly nested conditions are the only honest documentation of fifteen years of edge cases: a tax rule, a union agreement, a customer who pays enough to get special handling. We do not delete that. We pin the existing behaviour under characterisation tests first, so the logic nobody remembers is captured before anyone touches it. Then we change it in the open. The old code is not the liability: the behaviour encoded in it is the asset, and a rewrite deletes that on day one.
“Ship the MVP, iterate later.” There is no later once finance has closed the books against your numbers and an auditor is holding you to them. Version one is the contract. In an enterprise, the first release is not a hypothesis you get to revise next sprint. It is a commitment other people have already built on.
Optimise for time to safe reversibility
Startups optimise for time to first user. Enterprises should optimise for time to safe reversibility: how fast you can change one thing and prove you did not break the other two hundred wired to it. Concretely, that means feature flags on every change, contract tests between modules, and a rollback measured in minutes instead of committees. This is the same instinct that makes a composable architecture worth the effort. It is not novelty, but the ability to change one piece without holding your breath.
Once that client started measuring reversibility instead of velocity, the picture changed fast. First safe production change in six weeks. The average change went from a three-month, sign-off-by-committee event to a two-day reversible deploy. Numbers rounded, client unnamed: that is the price of talking about real work in public.
The one question a CEO should ask
You do not need to read the architecture to govern this. When a vendor or a new hire quotes startup gospel at you, ask one thing: what is the blast radius if this is wrong? If they cannot answer in a sentence, they are selling you someone else’s context.
That question does more than any framework, because it forces the person recommending the change to state, out loud, what happens when it fails, and in an enterprise, something always eventually fails. The teams that keep moving are not the ones that avoid failure. They are the ones that made failure cheap to reverse before they needed to.
So the worth-sitting-with question is the one everyone on your team is quietly avoiding: what is the worst blast radius hiding in your stack right now, the change nobody wants to be the one to make? If naming it is uncomfortable, that discomfort is the measurement. Talk to TrueForge and we will help you make that change reversible before you have to make it.