Two different Odoo versions, two different industries, three engineers moving between them — and the same root cause kept recurring: several parts of a system quietly disagreeing about the same fact. Payroll disagreeing with attendance. Tax logic scattered instead of centralized. A security secret stored somewhere a bad actor could also reach.
Our answer is never a fourth opinion. It's collapsing the disagreement into one definition everyone calls.
That's why our security hardening looks the same on both platforms even though we built it a year apart, independently: a recovery secret that lives in the database protects nothing from a database administrator. Both platforms keep it in the server config instead — a house pattern, not a coincidence.
The order we work in, whatever the symptom — payroll, VAT or a dashboard.
Every case study here opens with the sentence a client actually brought us. "Payroll is off by half a day" is a better starting point than a requirements document.
The bug is rarely the arithmetic. It's usually several parts of the system quietly holding different opinions about the same fact.
One day classifier. One tax category. One stock move. Everything else reads from it, so there is nothing left to drift.
Put the rule where it can't be walked around, keep the off switch out of reach, and back it with tests — the payroll classifier shipped with 19.
Each one links to the case studies where it did the work.
When several parts of a system each decide the same fact, they eventually disagree. We don't add a fourth opinion — we collapse the disagreement into one definition and make everything else read from it.
On MAFA, attendance sources were four portal settings and three hardcoded lists in the backend, which could offer one employee different options on different screens. Both screens now ask the same server-side method.
A recovery secret that lives in the database protects nothing from a database administrator. Security settings and recovery secrets live in the server config instead, on both platforms.
AI earns its place where a person can check the output. Our models never write to the database directly: they draft, and someone signs off.
The CRM assistant on the aviation platform only runs when a user asks for it, against a provider the client configures.
A rule that only lives on a screen can be bypassed by an import, a script or a busy person. We put it in the model: constraints, gates on stage changes, access checks on every data path.
On MAFA, an advisor role excludes payroll journal entries at both the entry and the line level, so they are filtered out of every query — not just hidden from a menu.
Carry forward automatically when the facts are clean; stop and make a person decide when they aren't. An unnoticed gap silently misstates a filed return — a warning makes someone look.
Failing on record 3 of 200 rolls the whole batch back and tells the user nothing useful. We process everything that can be processed and report the reasons for the rest, counted.
Every failure we meet becomes a rule: stale events are skipped, drifted fields are detected and repaired, and a failed upgrade rolls itself back.
MAFA's deployment pipeline upgrades only the modules a change touched, in dependency order, and rolls back to the previous commit if an upgrade fails.
A new logo is a setting. A new tax treatment is a category on the tax. A new operating company gets its document sequences automatically. The next change shouldn't need a developer.
On the aviation platform, adding an operating company provisions its sales order and payslip numbering with no configuration at all.
Tell us what's broken. Chances are we've already fixed a version of it.