Why we extend Odoo instead of forking its core
We build in Odoo 17, 18 and 19 by one firm rule: customisations live in separate modules, never in the standard source. Through the _inherit mechanism we extend models, views and business logic without overwriting the core classes. A direct fork of the core may feel faster at first, yet it freezes every future update. When a new major version arrives, each private change would have to be reapplied by hand. Clean custom modules stay upgradeable and can be lifted forward with tooling such as OpenUpgrade.
On the technical side we work with the Odoo ORM, the OWL front-end framework and QWeb templates. Interfaces run over XML-RPC, REST or webhooks, connecting DATEV, logistics providers or the line-of-business software you already use. AI is wired directly into the ERP: field-level extraction from incoming invoices, citation-grounded RAG over your master data, suggestion logic inside workflows, all running on open-weight models through our ESTAYA AI Platform on our own servers in Germany.
A typical engagement moves through process review, data model, staged modular delivery, test-data migration and training. This fits mid-sized companies with long-grown processes that now want to retire spreadsheets, Access databases and disconnected point solutions. Rather than bending your work into foreign software, we represent your logic in the data model itself.
- Extension via _inherit instead of a core fork, so updates remain feasible
- Version migration with OpenUpgrade scripts
- Integrations over XML-RPC, REST and webhooks
- Replacing Excel, Access and isolated tools with a clean data model
- AI inside the ERP on open models, with data staying in-house