Before you build your own ERP

When the conversation about a new ERP begins, it tends to start in the same place. One option: implement a standard system more or less as it comes, adapt your processes to fit, and accept the compromises that come with something designed for every business rather than yours. The other: build something of your own, shaped precisely for how your business operates, without the constraints the standard model brings.

The standard system has a genuine case. It is maintained, supported, legally current, and proven at scale. The constraint is that it was designed for the widest possible range of businesses — which means it fits most of them adequately and none of them exactly. For some companies that is fine. For others, the gap between how the system works and how the business works quietly fills with workarounds, parallel spreadsheets, and processes the software never quite handles. That is usually when a consulting firm offers to customise the standard system for you — which solves the fit problem but trades it for a different one: extensions that break on upgrades, and a dependency on the firm that built them. Or when building something of your own starts to feel like the answer.

The custom option is more tempting than it has ever been. Vibe-coding — building software by describing what you want to an AI and iterating on the result — has compressed what once required a substantial team and several years into weeks, sometimes days. Some CEOs are doing it themselves. The companies moving this way are not wrong about the economics.

What you set out to build is yours: the workflows, the interfaces, the logic shaped for how your company operates. What the build uncovers is another matter. Partway through, the accounting layer arrives. The statutory reporting. The VAT obligations and e-invoicing mandates for every jurisdiction you operate in. By then you are already invested — scope, budget, time. Stopping is not straightforward. So you build it. And from that point, you own the update cycle: every legislative change, every new reporting mandate, on government timelines that do not pause for your roadmap. Established ERP platforms carry this by design. Build your own, and your team carries it instead.

There is a third option, and in my experience it comes up later in the conversation than it should.

Take a solid, maintained ERP base — open-source options like Odoo are fully viable — and do not modify it. Use it for what it is built for: the accounting, the statutory obligations, the ready-made connections to banks, tax authorities, and the other business systems you depend on — and the processes close enough to the standard model that bending them costs less than owning them. Then build the experience your people actually work in — the screens and workflows shaped for how your business operates — on top of it.

Your people work in something built for them. The vendor absorbs the legislation. You never own what the vendor was built to maintain.

The model is not new. We have run it on FlexiBee, Dynamics, and Odoo — maintained systems carrying the statutory layer. Everything the team worked in day to day was built on top. The obligation stayed with the vendor. All of it was done the slow way, before AI changed the economics.

The logic has not changed.

The pull toward building your own is understandable. The constraints that made it impractical for most companies are weaker than they were. But what got cheaper was the build. The obligation to keep a statutory layer current did not move. Before the decision is made, it is worth knowing which option removes that obligation — and which one quietly accepts it.

If you are approaching an ERP decision and want to think through which route makes sense for your business, that is a useful conversation to have before the build starts.