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.

Share

Facing a similar challenge?

Tell us what you want to build or improve, and we will help identify the right starting point.