Custom ERP or off-the-shelf: what AI actually changed
For a long time the answer was obvious: pick a market solution and adapt to it. I have spent two years building custom ERPs for small companies, and the maths no longer works the same way.
When a small company starts looking for an ERP, it is usually offered two options. Either an off-the-shelf solution, solid and proven, billed per user per month. Or custom development, presented as a money pit reserved for companies that can afford a team for two years.
That reasoning used to be sound. It is far less true today, and I want to explain why with numbers and real cases rather than promises.
The real cost of an off-the-shelf ERP is not the licence
A twenty-person company deploying a market ERP will pay somewhere between 50 and 150 € per user per month. Over five years the software bill lands between 60,000 and 180,000 €. That is the visible part, the one on the quote.
The invisible part often costs more. There is the integrator, charging 600 to 1,200 € per day, needed for every meaningful change. There are the custom developments, because no business fits perfectly into a generic model. Above all there is the cost nobody measures: the time your teams spend working around the tool.
On one project I took over, the logistics team exported a file from the ERP every morning, reworked it in a spreadsheet, and pushed the data back in the evening. Two hours a day, every day, for four years.
That kind of workaround never shows up in a comparison table. It shows up in working days.
What AI genuinely changed
The killer argument against custom builds has always been development time. Stock management, user permissions, accounting exports, dashboards: months of repetitive work. That is exactly the part AI assistance has compressed.
Be careful about what it actually speeds up. AI does not design your business for you, it does not decide your data model, and it does not replace understanding the need. It accelerates the mechanical work: data access layers, forms, tests, documentation. On an ERP, that easily represents 60% of the codebase.
In practice, on the two ERPs I delivered this year, the first working module was in production within a week. Five years ago, with the same specification, I would have quoted two to three months.
The real advantage: the tool fits the business, not the other way round
Take a real case. A manufacturing laboratory works with recipes, raw materials, blends and batches. Profitability is not calculated per finished product but per recipe, factoring in material purchase costs and production losses.
No general-purpose ERP models that natively. You can get close with custom fields and bespoke reports, but you end up with a system nobody really understands and that breaks on the next version upgrade.
With a custom build the question disappears. The recipe is a first-class object, the margin calculation is written once with the actual business rules, and each profile sees what concerns them: the lab sees formulas, logistics sees stock, sales sees margins.
What custom allows and subscriptions do not
- Unify several brands in one back-office while keeping distinct customer-facing storefronts.
- Plug a conversational assistant straight into your data, respecting each employee's permissions.
- Refresh a dashboard every fifteen seconds instead of waiting for the overnight report.
- Change a business rule in a day, with no ticket and no integrator quote.
- Stay the owner of your data and your code, independent of a vendor's pricing plan.
That last point deserves attention. When your production tool belongs to someone else, every pricing change, every feature moved to a higher tier, every acquisition becomes a risk to your operations.
When off-the-shelf is still the right call
I am not going to pretend custom wins every time. There are situations where it is a bad idea, and they are worth stating plainly.
- Your business is standard and your processes look like your competitors': a market tool will do the job.
- You need to be operational in two weeks: even accelerated, development takes longer.
- You work in a heavily regulated sector where tool certification is mandatory.
- You have neither an internal technical contact nor a long-term partner: custom software with nobody to maintain it becomes a liability.
That last point matters most. A custom ERP is not a deliverable, it is an asset that lives with the company. The question is not only what it costs to build, but who will look after it in three years.
How to decide without getting it wrong
I always suggest the same exercise before recommending anything. List your ten most frequent processes, the ones your teams run every day. For each, check whether a market solution covers it natively, whether it needs heavy configuration, or whether it fits nowhere.
If seven or eight fit the standard, take the market solution. If half of them require workarounds, custom becomes seriously competitive, and more so if your business is going to keep evolving.
| Criterion | Off-the-shelf | Custom ERP |
|---|---|---|
| Time to start | Fast | About a week per module |
| 5-year cost | Subscription grows with the team | Upfront investment, then maintenance |
| Business fit | The business adapts to the tool | The tool follows the business |
| Changes | Ticket, quote, vendor timeline | Directly, on your priorities |
| Data ownership | With the vendor | With you |
What I take from it
Custom is no longer the luxury it once was. It has not become free either, and it remains a long-term commitment. But the barrier that made the question a caricature, development time, has dropped significantly.
If your teams spend their days working around a tool that is supposed to help them, it is worth running the numbers again. They will probably come out differently than they did five years ago.