The situation I see most often: the system was implemented by someone else, that contractor is no longer reachable, and Odoo “sort of works” — but every new task costs more than the last, reports do not add up, and part of the data simply never arrives. A technical audit of an Odoo project answers one question: extend or rewrite, and what will it cost.
When you need an Odoo technical audit
Not on a schedule — on symptoms. The most common ones:
- every small change takes days instead of hours, and the developer cannot explain why;
- after an update or a new module, something completely unrelated breaks;
- data in Odoo does not match the CRM, the bank or the till — and nobody can say how many records went missing;
- the system is noticeably slow although the server is “powerful”;
- you are changing contractor and want to know what exactly you are handing over;
- the project was built fast and cheap, including heavy use of AI, and nobody knows what is inside.
Hook-based connectors: why the sync “almost works”
This is the most expensive finding, because it does not fail with an error — it stays silent.
The typical implementation looks like this: a developer attaches a handler to the create or write event and assumes all data now reaches the external system. In practice the hook does not fire for every way data changes: batch operations and mass writes, file imports, changes made through standard wizards, actions triggered by other modules, cron jobs, changes through the API, and sometimes raw SQL left over from earlier migrations — all of it passes by.
The result: the connector does not guarantee data completeness. The gap accumulates quietly, gets noticed a quarter later during reconciliation, and the expensive part is not fixing the connector but reconstructing the missing period.
The right architecture here is different: not “catch an event” but guarantee completeness — an event queue with its own state, scheduled reconciliation of balances, a control count of documents per period, and the ability to replay any interval without creating duplicates. Checking this is a mandatory item in the audit.
Code without architectural planning — and why AI does not soften it
A separate category of recent projects: code written fast, with heavy use of AI, but without architectural planning. The symptoms are recognisable:
- duplicated code — the same fragment scattered across several modules, so a fix in one place never reaches the others;
- several different methods doing the same thing — each written separately for a specific task, and now nobody knows which one is “the right one”;
- dead code — fields, methods and whole models nobody calls, which still execute, still break and still need migrating on upgrade;
- logic incompatible with how Odoo works — bypassing the ORM, ignoring document states, a home-grown calculation instead of the built-in accounting and valuation mechanics;
- logic incompatible with the business process itself — code doing something that simply never happens in reality, holding together only because users have not yet pressed the wrong button.
It is worth putting the emphasis in the right place: AI is a tool. A powerful one, but a tool. The problem is not the tool but that generated code was accepted without an architectural decision and without review by someone who knows Odoo. Programming with AI should be done by a programmer — then the result is fine. How to check this while you are still choosing a contractor is covered separately: how to choose an Odoo implementation partner.
How the process looks when AI is used without these consequences: programming with AI and why tests now matter more than speed.
What exactly gets checked
The audit breaks into five blocks — and the most expensive findings are almost never in the code, they are in the accounting.
1. Architecture and code quality
Module structure and dependencies, adherence to Odoo mechanics (ORM, inheritance, document states), duplicated and dead code, customisations made outside modules, test coverage, git history. Separately — Studio on Community and configuration that exists only in the database and disappears the moment you move servers.
2. Integrations
Data completeness (see the section on hooks above), error handling and retries, idempotency, request logging and log retention, token and rate-limit handling, behaviour when the external service is down.
3. Data and accounting
This is the block that usually determines the cost of repair: correctness of inventory valuation and cost of goods, balances on interim accounts, unreconciled payments, discrepancies between stock and the ledger, duplicate partners and products, the consequences of earlier migrations.
4. Performance
Profiling slow operations and cron jobs, heavy computed fields, searches without indexes, runaway technical tables. The cause of slowness is almost never a weak server.
5. Infrastructure and process
Hosting and backups (and, above all, whether they have ever been restored), separation of production and staging, how deployment happens, access rights, version upgrades, dependency on a single person.
What you get at the end
Not “everything is bad, let us rewrite it”, but a document you can make decisions with:
- a list of findings with a severity level — what is broken now, what will break on the next upgrade, and what is merely ugly;
- for each finding, the consequence for the business rather than only the technical description;
- an estimate in hours to fix, split into stages;
- a recommendation per block: keep, extend or rewrite;
- separately, what should be done immediately — usually backups, access rights and data loss in integrations.
How long it takes and what it costs
For a typical small or mid-sized business project — from a few days to a week, depending on the number of custom modules and integrations. I work hourly (T&M), with the scope agreed in advance: a quick overview first to size the job, then the detailed review.
What I need from you: access to the database (a copy is fine) and to the repository with the custom modules. If there is no repository, that is already the first finding of the audit.
An audit pays for itself in the simplest way: it is almost always cheaper than one month of a team working in a system they cannot trust.
What happens next
After the audit there are three possible paths: you hand the report to your own team and they fix it; I take over specific blocks for ongoing support; or we run a controlled move to a sane architecture without stopping the business.
The full list of what I do in Odoo is in Odoo Services. Services and pricing are in the Shop section.
Frequently asked questions
Can the audit be done without access to the database?
Partly — code only. But the most expensive findings are usually in the data, so without the database the picture stays incomplete.
Will you hand the report to our own developer?
Yes. The document is yours and anyone can work from it. An audit does not oblige you to order the fixes from me.
Do we need an audit if the system works fine?
Before big changes — a version upgrade, a change of contractor, a new integration — yes. It is cheaper to learn about the problems before rather than during.
What if it turns out everything has to be rewritten?
That is rare. More often one or two modules need rewriting and the rest is cured by targeted fixes.
Technical Audit of an Odoo Project: What to Check and How to Read the Report