How to Choose an Odoo Partner in the UAE
· 13 min read · Faceela
We are an Odoo partner. That makes this page awkward to write and worth reading for exactly that reason: the only version of it that is any use to you is the version that still helps if you read it and then hire one of our competitors.
So here is the position stated at the top, before any of the qualifications. The product you are buying is fixed. Every partner in this market sells the same Odoo. What varies — completely, and far more than buyers expect — is what comes out the other end.
The same product implemented by two teams produces two different systems. Not two versions of the same system with different levels of polish. Two different systems: different data models under the same screens, different answers to the same question, one of which can be upgraded next year and one of which cannot. The licence you sign for is the smallest and least differentiated part of the transaction. The team is the transaction.
If Odoo is not yet a settled decision, the argument for and against the product itself is in what Odoo does well and badly in the UAE. This page assumes the product decision is made and the remaining risk is who builds it.
What the partner tiers actually mean
Odoo grades its partners — the labels have shifted over the years, but the structure is the familiar bronze, silver, gold ladder. Buyers read this as a quality ranking. It is not one, and this is the single most useful correction in this article.
Partner tier is primarily a commercial grade. It reflects the volume of Odoo subscriptions the partner sells and renews, and the number of certified people they employ. Both of those are real facts, and neither is a measure of whether your implementation will succeed.
| The tier tells you | The tier does not tell you |
|---|---|
| They sell a meaningful volume of Odoo licences | Whether any of those clients are still live and current three years later |
| They employ people who have passed certifications | Whether those people are assigned to you |
| They have a durable commercial relationship with Odoo SA | Whether they have ever delivered your industry's core process |
| They are unlikely to disappear next quarter | Whether they will hand you the source code when you leave |
| They have been through Odoo's onboarding | Whether they run tests, version control, or a real test environment |
Two consequences follow.
A high tier is not a reason to relax. Licence volume is compatible with a factory model: a standard configuration applied fast to as many clients as possible, which is excellent for a straightforward trading company and dangerous for anyone whose processes are not straightforward.
A low tier is not a reason to disqualify. Small, technically strong firms and independent consultants who have delivered in your sector for years may sit low on the ladder because they do not chase licence volume.
Certification deserves the same treatment. It proves someone sat an exam on the product. It says nothing about whether they have ever closed a month, argued with an auditor, or explained to a warehouse manager why the system will not let him do the thing he has done for eleven years.
Use tier as a filter for commercial durability, then throw it away and assess the actual team.
Industry experience: the questions that separate doing from reading
Every partner will claim experience in your sector. The claim is almost free to make. What is not free is answering specifics, and specifics are how you tell the difference in about fifteen minutes.
Ask about the ugly part of the process, not the clean part. Any partner can demonstrate a sales order. Ask instead: how do you handle a credit note spanning two VAT periods; what happens to landed cost when the shipping invoice arrives six weeks after the goods; how do you reconcile a customer who pays four invoices with one transfer and a short payment nobody can explain. These are the questions that consume the actual project.
Ask what they told a client not to do. A partner who has never talked a client out of a requirement has either never had an opinion or never been listened to. Neither is good. The answer to this question is the fastest read on whether you are buying advice or order-taking.
Ask where standard Odoo did not fit, and what they did about it. The right answer names a specific gap, a specific decision, and what it cost. The wrong answer is "Odoo does everything" — which is both false and the single most reliable predictor of a month-five crisis, because it means the gaps will be discovered during your project rather than before it.
Ask about a system they built three or more years ago that is now on the current version. This is the highest-value question in the whole list. It cannot be answered with a demo. It requires a named client history, a version path, and what each upgrade cost. Partners who build well can answer it in a sentence. Partners who build casually change the subject, and the version-locked systems in this market were all built by someone who could not answer this question at the time.
Ask what they would need from us to make this work. A partner who says "nothing, we'll handle it" is either inexperienced or telling you what they think you want to hear. The honest answer names your people by role: a finance owner who can decide, a data owner per domain, testers with authority to reject.
Ask about the compliance edge, in this market specifically. VAT treatment on designated zone movements and imports under reverse charge, bilingual document layouts, the e-invoicing mandate and the accredited service provider connection, end-of-service accrual and WPS if payroll is in scope. Do not accept "the localisation handles it". Ask what the localisation gives you and what remains to be decided by someone who knows your transactions.
The same discipline applies to the demonstration itself. A demo on the vendor's data proves the vendor can drive the vendor's data — the way to run one so it tells you something is set out in the questions to ask in an ERP vendor demo.
Reading a proposal
The price is the least informative number in a proposal. Four other things tell you far more, and all four are readable in an afternoon.
The scope boundary
Look for what is explicitly excluded. A proposal with no exclusion list has not been scoped; it has been priced. Every honest implementation has a list of things it is not doing, and a partner who cannot produce one either has not thought about it or has decided you will find out later.
Then look at how requirements are expressed. Modules are not scope. "Sales, Purchase, Inventory, Accounting, Manufacturing" tells you what will be installed, which takes an afternoon, and nothing at all about the work. Scope is expressed in processes: order to cash, procure to pay, month-end close, stock count, project billing. Count them. That number, not the module list, drives the effort.
The assumptions clause
Read it twice, then read it a third time as though you were the party trying to use it against yourself. This is where the scope actually lives.
Assumptions like "master data will be provided by the client in the agreed template, cleansed", "no more than three custom reports", "one legal entity", "testing to be completed within ten working days of handover" are not boilerplate. Each one is a trapdoor. They may all be perfectly reasonable — but each is a condition you have to meet, and if you cannot, the price you agreed is no longer the price.
The specific assumption to hunt for is anything about data. "Data migration of open items only" is a very different project from "data migration including three years of history", and the difference is usually invisible until someone in finance asks why last year's comparatives are missing.
The change request mechanics
Every project has changes. The question is what happens when one arrives. Ask who can raise a change, who approves it, how it is priced, whether the timeline impact is stated at the same time as the cost, and what happens when the two sides disagree over whether something is a change or a defect. That last one is the argument that poisons projects — the partner calls it a change, you call it something that should have worked, and there is no written mechanism to resolve it.
A partner with a clear, unembarrassed change process has run real projects. A partner who says "we don't really do change requests, we're flexible" is describing either a generous firm or one that will become inflexible precisely when the schedule tightens.
Who is actually assigned
The people in the pitch are frequently not the people on the project. This is so common it is almost a convention, and it is entirely fixable by asking.
Ask for named individuals against named work packages, with the percentage of their time allocated. Ask where they physically sit and in which time zone. Ask what happens if a named person leaves. Ask to meet the consultant who will run your workshops — not the sales lead, not the delivery director, the person who will be in the room on Tuesday.
The composition matters as much as the names. A team weighted heavily toward developers is telling you, before the project has started, how it intends to answer your requirements. That is not automatically wrong, and it is a signal worth reading against where the line between configuration and custom code actually sits, because the mix in the quote usually predicts the mix in the delivery.
A fixed price with no scope document is not a fixed price. It is a fixed argument, scheduled for month four.
The questions to ask in the room
Condensed, in the order they are most useful.
| Ask this | A bad answer sounds like | A good answer sounds like |
|---|---|---|
| Which of my requirements are not standard Odoo? | "Odoo does everything", or "we'll handle that in Studio" | A written gap list, produced before contract, each item classified as configuration, build or exclusion, and priced |
| Show me a system you built three or more years ago that is now on the current version | A fresh demo database, or "our clients don't really upgrade" | A named version history and what each upgrade cost |
| Who owns the custom code, and where does it live? | Vagueness, or code that exists only on their server | Written assignment to you, in a repository you can read today |
| Who is actually doing the work? | Senior people in the meeting, unnamed team on delivery | Named consultant, named developer, stated allocation, and where they sit |
| How will this be tested? | "We test everything before go-live" | A named test environment, dry runs of the data migration, business testers with the authority to reject, and automated tests on custom modules |
| Which version do we go live on, and when does it stop being supported? | A version number with no date attached | Both, plus what the next move will involve |
| What have you decided not to do? | Nothing, everything is possible | An exclusion list, in the scope document |
| What happens the day we stop paying you? | "That won't happen" | A database export, the source code, the credentials, and a documented handover |
| What do you need from us? | "Nothing, leave it to us" | Named roles, named decision owners, and the hours per week they will lose |
| What usually goes wrong on projects like ours? | "Nothing, if the client is committed" | A specific, unflattering, recent example |
Warning signs
Ordered roughly by how much damage they do.
"Odoo does everything." The single most reliable predictor of failure. It means the gap analysis has not been done, and gaps that are not found before the contract are found during the project, at your cost, with no leverage remaining on your side.
A price without a diagnosis. A quote produced without seeing your processes, your entity structure and your data is a quote for a phase, not a project. The shape of a real number and what drives it is set out in how an Odoo budget in the UAE is actually built — the point is not that cheap quotes are dishonest, it is that they are incomplete by construction.
A proposal with no exclusions and no assumptions worth reading. Either the partner has not thought about your project, or they have and decided not to share the thinking.
The pitch team is the entire evidence base. No named delivery team, no access to the consultant, no reference you can speak to unaccompanied.
Reluctance about source code and data. Any hesitation about assigning the custom code to you, giving you repository access during the project, or committing to a documented exit is disqualifying. Not concerning — disqualifying. It is the mechanism by which a supplier relationship becomes a hostage situation.
No test environment in the plan. No separate environment, no data migration dry run, no acceptance testing period with named testers: the plan is to test in production, whatever it says on the page.
Go-live dates that ignore your calendar. A cutover across your peak season, your statutory close, your audit or a fiscal year change is a plan written for the partner's utilisation. The right decision in the wrong week still fails.
Everything solved with code. A team that answers each requirement with development is building you an asset that depreciates annually. Ask for the configuration answer first, every time.
No opinion. The partner who agrees with every requirement is not being accommodating; they are transferring the design risk to you while charging you for expertise. You are paying for someone to say "that is a bad idea, and here is why".
Discounts that arrive by pressure. A price that drops materially at quarter end was either wrong before or is wrong now. Ask which, and ask what came out of the scope to fund it.
The part that is your fault, not theirs
An honest article about choosing a partner has to include this, because a meaningful share of failed implementations were not badly delivered. They were badly bought and worse governed.
The partner cannot decide your pricing policy, cleanse your item master, tell your operations director that the process has to change, or make your finance manager attend testing. Projects stall on client-side decisions more often than on supplier-side work, and every day of that is billed to you regardless of fault.
So the second half of choosing well is arriving as a client worth working with. Name decision owners per domain and give them authority. Free the testers properly, not nominally. Put a named internal person in place to own the configuration after the consultants leave — the absence of that person is the most common reason a system that went live successfully is unusable three years later, and it costs a real salary that belongs in the business case.
And keep watching after go-live. The period when a project quietly fails is not the launch; it is the weeks afterwards when attention moves on and the workarounds start, which is the argument in why the most dangerous day of your project is not day one.
If you are already mid-project with the wrong team, changing partner is possible and it is not a small operation — the honest version of what that involves is in how to rescue a stalled implementation. It is nearly always better to spend two more weeks on selection than six more months on recovery.
Two teams, two systems
Come back to the claim at the top, because everything else here follows from it.
Give the same Odoo, the same requirements and the same budget to two competent-looking partners. One produces a system where standard flows are used as standard, the genuine gaps are named modules with tests in a repository you own, the data is clean because somebody insisted, and next year's version move is a quotable exercise. The other produces a system that works on go-live day and is a thicket underneath: a hundred Studio fields nobody can account for, Python in automation rules that no register mentions, overrides on core logic, no tests, and an upgrade eventually quoted as a reimplementation because that is genuinely cheaper.
Both went live. Both looked the same during the first quarter. The difference is invisible until the first version move, by which time the decisions that caused it are two years old and the people who made them have moved on.
You cannot inspect this after the fact without a technical review. You can only buy it in advance, by choosing a team whose method is written down before the project rather than described in a meeting — which is the reason the method we work to is published in full rather than presented on a slide.
If you want a second opinion on a proposal you are holding, including one from another firm, that is a smaller and far cheaper exercise than the project it protects. It is where our Odoo implementation work usually starts, and it sometimes ends with us telling you to sign with somebody else.