Engineering
Why we build on Odoo instead of replacing it
- 2 min read
Replacing a running ERP looks cleaner on paper and costs a year before anything works. Building on it has a different price — this is it.
The most common Odoo request we hear is not “install it”. It is “we have it, and it will not do this one thing”. The easy answer is to propose a new platform: a clean model, no legacy, none of the custom fields somebody added in 2021 and forgot. The easy answer costs a year before the new system issues its first invoice.
What gets replaced is not the software
What gets replaced is not the software. It is what the company learned while using it — the chart of accounts, the approval cycle, the cases the accountant handles by hand because nobody ever wrote them into a specification. All of that lives in the database and in no document anywhere. A new system starts from zero on every bit of it, and the first person to pay is the one who thought they were saving.
Start at the boundary, not at the system
So we start at the boundary rather than at the system. What does Odoo actually own — invoices, stock, partners — and what does the client want to do that it cannot? In most cases the thing they want lives outside the ERP and needs exactly four things from it: read, write, an event when something changes, and one authentication.
Those four have a price. Odoo’s external interface is slow when called in a loop, its model shifts between versions, and any custom field the client added is now part of your contract whether you documented it or not. Hence the rule: one layer knows Odoo, everything else knows our contract. When the client upgrades 16 to 17, one file gets fixed.
The event matters more than the read
The event matters more than the read. A system that asks Odoo every minute whether anything changed works beautifully on demo data and falls over on real data. What we build receives change instead: Odoo announces, we store locally first, then process. The difference is that a ten-minute network outage becomes a delay rather than a loss.
When replacement is the right answer
When is replacement the right answer, then? When what the client wants sits inside the ERP’s own scope and contradicts its model — not when it sits outside it. Telling those apart takes a week of reading, and saves the year after it.
MORE
Read next
Gamification in a product that is not a game
Points and badges lift usage for two weeks and then become noise. What survives them.
Read moreAn assistant for many companies: where it breaks first
The hard part of a multi-tenant chatbot is not the model. It is guaranteeing that one tenant never reads a line of another’s data.
Read moreArabic is not mirrored English
What we learned building bilingual interfaces that genuinely work in both directions.
Read moreNo model without an eval gate
How we stop a model reaching production before it proves it beats the one already there.
Read moreBoundaries before features
A feature built across a broken boundary costs more later than it saved — and why we spend two weeks on something that never appears on screen.
Read moreFacing a similar challenge?
Tell us what you want to build or improve, and we will help identify the right starting point.

