How to Choose an Odoo Implementation Partner: Questions, Guarantees and Red Flags

The cost of choosing the wrong contractor is not the money you pay for the implementation. It is a year of your company working in a system it cannot trust: reports have to be double-checked by hand, every change costs an unpredictable amount, and nobody can answer why something was built the way it was.

Below is what is worth finding out before signing. The order is not accidental: the first question matters most.

Who exactly will work on your project

The person selling the project is usually not the person building it. So ask it literally: who personally will write the code, what Odoo experience they have, and how many projects they have taken to production.

What you want to hear back — and preferably to have written into the contract:

• the team by name, with seniority and area of responsibility;
• a guarantee that the people on the project hold the relevant qualifications — this is a normal requirement, not an insult;
• who owns the architecture — it has to be a specific person, not “the team”;
• who does code review, and whether it happens at all;
• what happens if the key developer leaves — is there anyone else who knows the project.

If the answer to this is generic (“we have a strong team”), you can skip the rest of the questions.

AI in development: not a reason to pay less, and not a reason to refuse

AI is a tool. A powerful one, but a tool. It speeds up writing code, and there is nothing wrong with that — I use it myself. The question is not whether the contractor uses AI, but who makes the decisions.

Programming with AI should be done by a programmer — someone who understands Odoo, sees the architecture as a whole, and is able to reject a generated solution because it does not fit the system. When that person is missing, AI simply produces faster what will later take a long time to untangle: duplicated code, several different methods for one task, dead fields and models, logic incompatible with Odoo’s mechanics or with the real business process.

What to ask:

• whether generated code goes through human review, and who does it;
• who makes the architectural decision before the code is written;
• whether there are tests on the critical logic — those are what show the code was understood rather than merely pasted.

The simplest check: ask them to explain any fragment of code from a previous project. Someone who thought it through will explain it in a minute.

More on how the development process should be organised with AI, and why full test coverage now matters: in a separate article.

Architecture questions — before the start, not after

• What do you propose to do with standard Odoo functionality and what with custom code — and why exactly that split?
• How do you plan to upgrade to future versions with these customisations in place?
• Will Studio be used — and what happens to it when the database moves to another server?
• How are production and staging separated, and what does deployment look like?

“We will do it in Studio, it is faster” for a system meant to live for years is a deferred invoice, not a saving.

Integration questions: not “we will connect the API” but “how do you guarantee completeness”

The most expensive integration problems are not errors but silence: the connector runs, yet some documents simply never arrive. So phrase it this way:

• how does the connector behave when the external service is unavailable — is data lost or does it wait in a queue?
• can a period be replayed without creating duplicate documents?
• how do you verify that exactly as many documents were transferred in a month as there were?
• are requests logged, and how long are the logs kept?

Why this is critical and what a hook-based architecture leads to is covered here: technical audit of an Odoo project.

What belongs in the contract

• Code in your repository — not “we will hand it over at the end”, but from day one. It is the simplest protection against dependence on a contractor.
• Accounts registered in your name: server, domain, hosting, mail services, payment provider accounts.
• A guarantee of the qualifications of the people on the project, and the procedure for replacing a developer.
• A warranty period for fixing defects in delivered functionality.
• Transparent time reporting: what exactly was done in those hours, not “development — 40 h”.
• Documentation, at least a description of the custom modules and integrations.

Red flags

• A fixed price without process discovery. That is not a budget guarantee — it is a guarantee that whatever you did not spell out will be cut from scope.
• “We will do it all in Studio, it is faster.” Faster today, more expensive at the first migration or upgrade.
• No git. If the code lives only on the server, it effectively does not exist.
• A single developer with no backup and no documentation.
• Deadlines promised before any conversation about your processes. “We will implement it in two weeks” without a single question about your accounting is a sales pitch, not an estimate.
• Unwillingness to show previous code, even anonymised.

How to test a contractor before the big contract

Two approaches work. The first is a pilot task: small but real, taken from your own list. It shows everything — how they ask questions, how they estimate, how they hand over, whether tests exist.

The second, if the system already exists, is to commission an independent technical audit before handing the project over for further development. It often changes the task list itself.

Hourly or fixed price

A fixed price looks safer, but it only works where the scope is genuinely defined — a single module with a clear specification. For an ERP implementation the scope is refined as you go: half the real requirements appear only when people first see the system with their own data in it.

So for an implementation the honest format is hourly billing with transparent reporting and stages: you see where the hours go and can stop or reprioritise at any stage.

If you are looking for a contractor

What I do in Odoo and how I work is set out in Odoo Services. If the system was implemented before you and you need to understand its condition, start with a technical audit.

Frequently asked questions

Do we have to hire an official Odoo partner?

No. Partner status describes a relationship with the vendor, not the quality of the code on your project. What matters more is who personally does the work and what the contract says.

How much should an Odoo implementation cost?

The numbers vary so widely that the figure itself is the wrong thing to compare. Compare transparency instead: what it is made of and what happens if the scope changes.

Can we start small?

Yes, and it is the best scenario: one process taken to a working state teaches you more than six months of specification meetings.

The contractor uses AI — is that bad?

No, provided the code is reviewed by someone who knows Odoo and the architectural decisions are made before the code is written, not after.

We already started with another contractor and have doubts. Too late?

No. A technical audit at any stage is cheaper than finishing a project that will have to be redone.