You Don't Have an ERP Problem. You Have a Lock-In Problem.

Somewhere in your company there is a spreadsheet doing a job your ERP was supposed to do. Probably several. A scheduling sheet that a planner rebuilds every Monday because the module that would automate it was quoted at $180,000 and nine months. A quoting workbook with fifteen tabs of tribal logic, because encoding it in the system of record needed a consultant your team stopped calling after the second change order. A customer portal that is actually a shared inbox, because the vendor's portal add-on wants a per-seat license and still doesn't match how your customers order.

Nobody decided this on purpose. Each spreadsheet was a rational response to a quote. And each quote was a rational price, in a world where custom software meant senior engineers typing for months. That world ended somewhere around 2025. The quotes haven't noticed yet.

This post is about the gap between those two facts. Why lock-in was the financially correct choice for two decades, what specifically changed in the cost structure of custom software, and why the teams that use the change carelessly are going to hurt themselves in a very predictable way.

01. Lock-in is a behavior, not an architecture

When people say "vendor lock-in" they usually mean something technical: proprietary data formats, closed APIs, a codebase only the vendor can touch. That exists. But the lock-in that costs real money is behavioral, and it shows up in three stages.

Stage one, you ask. A workflow doesn't fit the system, so you request the customization. The quote comes back at six figures with a next-fiscal-year start date, and the request dies in a steering meeting.

Stage two, you adapt. The process bends to the software. The planner learns the workaround, the workaround becomes the process, and the spreadsheet becomes load-bearing. Nobody prices this stage, which is what makes it dangerous: rekeying between systems, reconciliation at month-end, the errors that come from both.

Stage three, you stop asking. This is the expensive one. New ideas get filtered before they reach anyone who could act, because everyone already knows the answer is a quote nobody will approve. The roadmap doesn't shrink on paper. It shrinks in the questions people no longer raise.

The same three stages apply whether the anchor system is NetSuite, SAP, or your own software circa 2012 with a vendor that got acquired twice. By stage three the company has quietly reorganized itself around what its systems will tolerate. That is the real cost of lock-in, and it never appears on an invoice.

02. The old math, and why staying put was correct

The people who signed those decisions had the math on their side.

For most of the last two decades, implementation consumed 60-70% of a custom software project's effort. Humans typed every line, so cost scaled with scope, and scope on anything touching an ERP is never small: integrations, permissions, audit trails, the edge cases in fifteen years of contract variants. A custom scheduling module quoted at $180,000 was a defensible estimate of senior-engineer months.

Migrations were worse, because the denominator was bigger and the risk was existential. The cautionary tales are famous for a reason. Lidl walked away from its SAP rollout after seven years and roughly €500M sunk (Handelsblatt, 2018). Birmingham City Council budgeted about £19M for an Oracle migration and has publicly reported costs past £100M (BBC, 2024). Against those anchors, "we stay on the old system and pay maintenance" reads like fiscal discipline. Standard enterprise maintenance runs around 20-22% of license cost per year, which means you re-buy the system every five years, and CFOs approved it anyway, because the alternative was a seven-figure bet with a documented failure mode.

So the equilibrium held. The vendor priced customization at typing-time rates. The buyer compared that price to the invisible cost of workarounds, misjudged the workarounds as free, and stayed put. Multiply by twenty years and you get the current landscape: mid-market companies with excellent ledgers and stalled roadmaps.

03. The inversion reached your vendor's quote

We have written before about the great inversion: with capable agents in the loop, the implementation share of software effort collapses from 60-70% to single digits, and planning plus verification expand to fill the space. On GitHub, 46% of code is now AI-generated (GitHub, Oct 2025). That number describes ordinary daily production work, not a frontier-lab demo.

Apply that to the lock-in equilibrium and both sides of the old comparison move at once.

The custom module that was quoted at $180,000 was mostly implementation hours. Most of that line item is now automatable. The judgment work that remains (what exactly should this do, how do we know it works, how does it integrate with the system of record) was always a minority of the bill, and it is the part that still costs what it used to. The honest new quote for the same scope is a fraction of the old one, delivered in weeks. We price work like this at fixed cost against a one-page scope, and the numbers land where a serious freelancer used to be, for work that used to require a consultancy bench.

Migrations moved even more, because the inversion changes the shape of the project, not just the price. A big-bang rewrite was never expensive because rewriting was hard in principle. It was expensive because holding an entire legacy system in human heads while retyping it took years, and the risk compounded over every one of those years. Agents change the unit of work. A bounded subsystem (one integration, one reporting pipeline, one module of business logic) can be specced, rebuilt, and verified as its own project, with its own price and its own rollback plan. We shipped a migration off a 2018 monolith in two weeks with zero post-handoff incidents, and the whole trick was scope: the subsystem was small enough to verify completely. String enough of those together and you have left the legacy system without ever having bet the company on a cutover date.

The stage-three question, the one your team stopped asking, deserves a second ask, because the thing the old quotes were anchored to, months of human implementation time, no longer exists.

04. The part where everyone gets hurt

This is the half of the argument that vendors selling speed leave out, and the reason this post does not end with "point Copilot at your ERP and go."

The same inversion that collapsed implementation cost also collapsed the cost of producing bad software. AI-generated code ships 1.7x more production issues (CodeRabbit, 2025). Teams with heavy AI use report PR review time up 91% (industry study, 2025), because the volume of plausible-looking code outruns any team's capacity to line-by-line audit it. Forrester expects roughly 75% of companies that try to build agentic systems on their own to fail (Forrester, 2025). Taken together, the numbers locate the new bottleneck. Generation stopped being it, verification became it, and most teams have not built the verification muscle.

Now put that failure mode next to the systems this post is about. An experiment in a greenfield app fails cheap. Code that touches your ERP touches your ledger, your inventory, your invoices, the numbers your auditors sign. This is the worst possible place in your company for unreviewed generated code, and it is exactly where the temptation to "just automate the workaround" points. A generated integration that silently mishandles tax rates on historical contracts is not a bug. It is a restatement.

The slop problem is why cheap AI dev shops will burn a cohort of mid-market companies over the next few years, and why the burned companies will conclude, wrongly, that the new math was a mirage. The math is real. It just doesn't come with the discipline included. Speed came from the models. The two things that make speed safe near a system of record, specification and verification, have to be supplied by a methodology.

05. What the disciplined version looks like

We run every project through the same loop, and each piece exists to counter a specific failure mode from the previous section.

The spec comes first, and it is machine-readable. Before any code, the workflow gets written down as a structured spec: intent, requirements, acceptance criteria an agent can verify. For ERP-adjacent work this step has a side effect customers don't expect: it is usually the first time the actual process (not the official one, the one in the planner's spreadsheet) has ever been made explicit. Disagreements about what the software should do surface here, on a document, instead of three weeks into a build.

The work runs in risk-scoped mini-cascades. Scope is decomposed into bounded iterations, sized by blast radius rather than by a sprint calendar. A read-only dashboard against ERP data is low risk and ships in days. Anything that writes to the ledger gets a narrower scope and a heavier verification gate. Each cascade is priced and verified on its own, which is what makes "subsystem by subsystem" a real migration strategy instead of a slogan.

Review is evidence-based. Every PR arrives with an evidence package: test results, screenshots, traces, and a link back to the spec requirement it implements. This is the answer to the +91% review problem. A human still approves everything, but they audit evidence against acceptance criteria instead of reading every generated line. It is also what makes the work reviewable by the people who actually know the domain. Your operations lead cannot read a diff. They can absolutely read "requirement r3: tax rates must reflect the contract in force on the invoice period" next to a passing test that proves it.

The ERP keeps the ledger. This one is a scope decision rather than a platform feature, and it is the difference between this approach and a rip-and-replace pitch. NetSuite and SAP are good at being systems of record. The custom layer we build sits around them: the scheduling, quoting, portals, and approvals that were never going to fit a configuration screen. Integration over replacement, until the day a replacement is genuinely the smaller project.

06. We ran this on ourselves first

We didn't arrive at the ERP framing by market research. We had the same mess: invoicing in a forked Excel template, project tracking across three tools, allocation in one PM's head. We used our own platform to replace our ERP module by module, and we published the write-up with the failures left in, including the over-specified first spec that produced technically-correct, unmaintainable code, and the cross-module interface gap that cost us a rework cycle.

That project is why this post keeps insisting on specs and evidence instead of speed. Speed was never the hard part. On our own build, the agents were consistently faster than our ability to say precisely what we wanted and prove we got it. Every failure we hit traced back to one of those two gaps. The methodology is just those lessons, written down and made repeatable.

The stalled roadmap at an ERP-locked company is the same project with different table names. The domain knowledge is already in the building, sitting in the heads of the people who run the workarounds. What was missing until now was a price of implementation that made encoding it worthwhile, and a verification practice that makes the result trustworthy next to a ledger.

Both exist now. The quotes your team stopped asking for deserve a second ask.

Thanks for reading this blog! If you have a workflow your ERP refuses to do, or a migration that has been "next year" for five years, we'd rather look at the specifics than argue in the abstract. Send it over and we'll tell you straight what the new math says about it. The worksheet version of this post ships as a free report on the homepage. Next: how we're replacing our own ERP →

References

1. GitHub, Octoverse 2025, 46% of code on GitHub is AI-generated (Oct 2025).
2. CodeRabbit, State of AI Code Quality (2025), 1.7x more production issues in AI-generated code.
3. Industry study (2025), PR review time up 91% in teams with heavy AI use.
4. Handelsblatt (2018), Lidl abandons its SAP rollout after seven years and approximately €500M.
5. BBC (2024), Birmingham City Council's Oracle implementation, budgeted near £19M, reported past £100M.
6. Forrester (2025), prediction that roughly 75% of companies building their own agentic systems will fail.
7. Steerdev, The Great Inversion, the cost-structure shift this post applies to vendor economics.
8. Steerdev, How We're Replacing Our ERP With AI Agents, the dogfood project behind section 06.