Odoo is a capable application framework, not only an ERP. Given that, the path of least resistance for any new requirement is to build it as an Odoo module. The data is already there, the user accounts are already there, the framework is already running. Most of the time that is the right call. Sometimes it is how a clean platform slowly becomes an unmaintainable one. Either way, the decision deserves to be made rather than defaulted into.
The case for building inside Odoo
When a feature operates on Odoo's data and follows Odoo's grain, build it inside. It inherits the data model, the access control, the views, the audit trail, and the user accounts for free. A separate service would have to reproduce all of that, or integrate back to borrow it. For anything that is genuinely part of the business operations Odoo already runs, inside is correct, and a separate service would be pure overhead.
The signs it should be built alongside
Some requirements are inside Odoo only by an accident of convenience. The signs that something wants its own service:
- A different load profile. A public-facing, high-traffic endpoint sharing workers with the interactive back office means one can starve the other. Work whose traffic shape is nothing like ERP usage often wants its own process.
- A different release cadence. If a component needs to ship daily while the ERP changes quarterly, coupling them forces the slow thing to gate the fast thing, or the fast thing to destabilise the slow one.
- A different failure tolerance. Something that may crash and restart freely should not share a process with the system of record.
- It barely touches Odoo's data model. If a feature uses almost none of Odoo's models and mostly carries its own, the "it is already there" argument is hollow. It is not using the platform; it is just hiding inside it.
The real cost of coupling
Everything built inside Odoo is tied to Odoo's upgrade cycle, its dependency versions, its worker model, and its release rhythm. That coupling is free while everything moves together, and expensive the moment one part needs to move differently. The question is rarely "can Odoo do this," because it almost always can. The real question is "do I want this thing's lifecycle welded to the ERP's lifecycle for the next several years."
How we decide
- Operates on Odoo's data, ERP-shaped load, same cadence as the business: build inside.
- Different load, different cadence, different failure tolerance, or barely touches Odoo's models: build alongside, and integrate across a clean boundary.
- Genuinely unsure: build inside, but keep it as a self-contained module with a narrow interface, so that extracting it later is a move, not a rewrite.
The note for the file
"Odoo can do it" is true and not the point. A platform stays maintainable by being a deliberate set of things, not an accreted pile of everything that was convenient to add at the time. The alongside option costs an integration boundary. The inside option costs a lifecycle welded together. Pick the cost you actually want to carry.