Loading page
Most Odoo customisation debt is not caused by writing code. It is caused by writing it in the wrong place - a patched core file, an inherited view nobody can read, or a server action holding business logic. We build the same behaviour as a module, so the next version upgrade is an afternoon rather than a project.
The business problem
Odoo does eighty per cent of what the business needs. The remaining twenty per cent is being handled by spreadsheets, re-keying, and a customisation that broke the last upgrade.
The question is never "can Odoo do this" - it is "what is the smallest, best-bounded change that does it and still upgrades".
What we build
Domain logic in its own addon, with its own tests, its own access rules, and no core file touched.
New fields, states, approvals and validations on the models you already use.
Invoices, delivery notes and statements that look like your company sent them.
Every override is written knowing it has to be read again at the next version.
Reference architecture
Boring on purpose: one API surface, one source of truth per concept, integrations at the edge, and an audit trail from day one. Diagrams are produced per project and included in the handover pack.
Related
FAQ
That is the thing we are optimising for. Work lives in its own module, core files are never edited, and every override is documented with what it depends on - so an upgrade is a review of a short list rather than an archaeology exercise.
Yes, and it usually starts with reading them. We will tell you honestly if the cheaper path is to rewrite a module rather than extend it.
A short paid discovery: we map the process, agree the architecture and produce a scoped plan you own regardless of who builds it.
Fixed for discovery and clearly bounded phases. Time and materials for ongoing product development, with a monthly cap.
You do, from the first commit, in your own repository.