What to require from a partner · Walid Redwan — Odoo Business Apps Implementation

Almost every partner will demo well. Demos are rehearsed, run on clean data, and avoid the parts of your business that are difficult. They tell you very little.

What follows is what to ask for instead.

Require these in writing

Not preferences. If a partner will not agree to these, that is your answer.

Require	Why it matters	How to check it now
A named consultant	You want the person who will configure your system, not an account manager who disappears after signature.	“Who exactly will do the work? Can I meet them before I sign?”
You own the code	Custom modules you paid for must be yours, in a repository in your company’s name.	“Which git account will the repository sit under?”
A written fit-gap before build	It is the only way to know what is standard, what is configuration and what is custom.	“What do I receive between scoping and building?”
Callable references	Not logos. Companies of your size you can telephone.	“Can I speak to two clients running something similar?”
A change mechanism	Scope will change. You want a defined process, not an argument.	“How does a new requirement get priced mid-project?”
An exit	If it goes wrong, you want your data, your code and your documentation.	“What do I hold if we part company in month five?”

The code ownership point is the one people forget, and it is the one that traps them. If your customizations live in a repository the partner controls, changing partner means rebuilding.

Questions that separate delivery from sales

Ask these in the first meeting. The quality of the answer matters more than the answer.

“Which of our requirements should we drop?” A partner who cannot name one either has not read your document or will agree to everything and invoice for it later.
“Where would you use standard Odoo even though it does not exactly match how we work?” You are testing whether they will defend the standard route. The good answer includes a process you would have to change.
“What normally goes wrong on projects like ours?” Anyone experienced has a fast, specific answer. Vagueness means inexperience.
“Show me a custom module you built for another client.” Not the screens — the repository, the documentation, the commit history.
“What do you need from us, and how many hours a week?” A partner who says “very little of your time” is either inexperienced or telling you what you want to hear.
“What happens after go-live?” Ask for the shape of support: response times, who answers, what it costs.

Red flags

A fixed price on a scope nobody has written. Either the price has heavy contingency in it, or the scope will be argued about later. Usually both.
Selling from the demo. Every business looks well served by a demo database.
No fit-gap step. Straight from sales meeting to build means the analysis is being skipped, and you will pay for it during testing.
“We will do it all in Studio.” Studio is useful and has limits. Used to avoid proper design, it produces a system nobody can maintain or upgrade.
Only one person to talk to, ever. Holiday and illness become your problem.
Reluctance to name the version. Odoo changes yearly. A partner who is vague about which version you are buying is vague about something.
Discount pressure with a deadline. Implementation prices do not expire on Friday.

Comparing proposals properly

Send the identical requirements document to everyone. Then compare on structure, not on total:

What is included? Data migration, training, testing support, hypercare and documentation are frequently missing from the cheaper quote, and they are not optional.
How many days, by role? A number of days tells you far more than a total price.
Which edition and how many users? Licences are a recurring cost for years.
What is explicitly excluded? The most informative section of any proposal.
What are the payment stages? They should attach to delivered and signed phases, not to the calendar.

A proposal that is 40% cheaper is almost never better value. It is usually a smaller scope, and you will meet the difference as change requests.

What to ask a reference

Speak to two clients, without the partner on the call. Ask:

What went wrong, and how did they handle it?
Did the price change? Why?
How much of your own team’s time did it really take?
Did the same consultant stay for the whole project?
What do you wish you had insisted on at the start?
Would you hire them again for the next phase?

The fourth question catches the most common problem in this market: a strong consultant sells the work, and a junior delivers it.

A simple scorecard

Score each partner 1–5. It stops the most confident presenter from winning by default.

PARTNER ..................................

Understood our business ................ /5
Named the consultant we will work with . /5
Challenged at least one requirement .... /5
Fit-gap included before build .......... /5
Code ownership agreed in writing ....... /5
References checked and positive ........ /5
Migration, training, hypercare included  /5
Support terms clear .................... /5
Exit terms clear ....................... /5

Price ........... Days ........... Edition ...........
Excluded .................................