Summarize with AI

Google AI ChatGPT Perplexity Claude.ai Grok

Odoo Consultant: Do You Need Functional or Technical?

Key Takeaways:

• “Odoo consultant” describes two different jobs. Functional consultants decide how the business runs inside Odoo. Technical consultants build what configuration can’t reach.
• Buy the wrong one and the symptom is predictable: a technical consultant builds a custom module for something Odoo already does, or a functional consultant configures around a gap that needed forty lines of Python.
• Most problems described as needing development need configuration instead. Start functional.
• The scarcest and most valuable person is the functional consultant who reads code well enough to know when to stop configuring. Rare, and worth paying for.
• Your first question isn’t which to hire. It’s whether your problem is a process question or a product limit.

Introduction

Here’s the tell that you bought the wrong kind of consultant.

Six weeks in, there’s a custom module doing something Odoo ships natively. The code works. Nobody on the team had configured that part of Odoo before, so nobody recognized the native feature, and now you own custom code that will break at the next upgrade and has to be deleted.

The mirror image happens too, and it’s quieter. A functional consultant spends three weeks building an elaborate workaround out of automated actions and server actions, because the clean answer was a small Python method nobody in the room could write.

Both failures come from the same place: treating “Odoo consultant” as one job. It’s two, and which one you need depends on whether your problem is a process question or a product limit.

The two roles, concretely

Functional consultant

Decides how your business will run inside Odoo. Process discovery, chart of accounts design, item and variant strategy, warehouse and routing structure, approval workflows, user training, and the mapping between how you work today and how you’ll work in the system.

The output is decisions and configuration, not code.

The distinguishing skill is product depth: knowing what Odoo already does. That sounds unglamorous and it’s the single most valuable thing on an Odoo project, because it’s what prevents you paying to rebuild native behavior.

Technical consultant

Builds what configuration genuinely can’t reach. Custom modules, ORM work, inherited models and views, server actions, API integrations, data migration scripts, custom reports, and performance work on slow queries.

Python, plus Odoo’s own framework conventions, which differ enough from generic Python to matter.

The distinguishing skill is restraint: knowing what not to build, and extending through supported points rather than overriding core. Code written by someone who read core before extending it survives upgrades. Code written around it doesn’t.

What each one owns

Which one your situation needs

Four situations, and the first covers most people.

“Odoo doesn’t do what we need.” Start functional, almost always. In our experience the large majority of these turn out to be configuration, a native feature nobody found, or a process that could change more cheaply than the software. Bring a technical consultant in after a functional one has confirmed the gap is real.

“We need Odoo to talk to another system.” Technical, from the start. Integration is code, and the design decisions about record ownership and idempotency are technical ones with commercial consequences.

“Odoo is slow.” Technical. Slow Odoo is usually query patterns, unindexed searches, or stored computed fields recomputing more than they need to. Configuration rarely fixes it.

“We’re implementing from scratch.” Functional leads, technical supports. The sequence matters: process decisions shape the data model, and the data model constrains everything a technical consultant could later build. Get that order wrong and you pay for rework.

One pattern worth naming. If your question starts with “how should we…” it’s functional. If it starts with “can Odoo…” it’s usually functional too, because the answer is often yes and nobody knew. It’s technical when the question is “Odoo can’t, so how do we…” and someone competent has already verified the first half.

Who shouldn’t call us

If nobody has configured the relevant Odoo module in a demo database yet, do that before hiring anybody. An afternoon in a free trial answers a surprising share of “can Odoo do this” questions, and it costs nothing.

If your problem is that your process is genuinely broken, a consultant won’t fix it. Odoo will encode whatever you tell it, more rigidly than your spreadsheets did, and you’ll have paid to make the broken process harder to change.

And if you want a technical consultant because a functional one told you something wasn’t possible and you didn’t like the answer, get a second functional opinion first. Sometimes the first one was wrong. More often, buying code to route around a correct answer is expensive.

The hybrid, and why they’re worth the premium

The most valuable person on an Odoo project is the functional consultant who reads Python well enough to know when configuration has run out.

They don’t write the module. They recognize the boundary, which is the decision that determines whether you get forty lines of clean inherited code or three weeks of automated-action gymnastics that nobody can maintain.

That combination is genuinely scarce. Functional people mostly come from business and process backgrounds, technical people from development, and the market rewards depth in one rather than breadth across both. When you find someone with both, they cost more and they’re usually worth it, because the decisions they make early are the expensive ones.

Absent that person, the workable substitute is a functional and a technical consultant who talk to each other regularly, with an explicit rule that no custom development starts without the functional consultant confirming the native gap. That rule is cheap and it prevents the commonest expensive mistake.

What to ask each one

Ask a functional consultant:

• “Walk me through something you configured that a client expected to need development.” Tests product depth directly.
• “How would you model our variants?” Listen for them asking about reporting and stock before answering.
• “When have you told a client to change their process rather than the system?” Tests whether they’ll push back.

Ask a technical consultant:

• “How do you add a field to an existing model without touching core?” Tests upgrade-safe extension. Weak answers modify core Odoo.
• “When is a custom module the wrong answer?” Strong candidates reach for configuration, automated actions, or a native feature first.
• “What breaks in custom code at a major version upgrade?” Real experience produces specifics.

The strongest signal for either role is the same one: having lived with their own work through an upgrade. Both roles make decisions whose cost lands twelve months later, and only people who were still there when it landed have calibrated judgment about it. That’s the same axis covered in hiring Odoo engineers.

Where my own advice is self-serving

I’ve told you to start functional, and I should flag that this is convenient for me.

Functional engagements are easier for us to scope, easier to price, and they very often reveal work that leads into a technical phase. A partner recommending “start with discovery” is recommending the thing that also happens to open the door to everything after it. You should read that with some suspicion.

The reason I still believe it is the failure asymmetry. A functional-first project that turns out to need development loses a few weeks and some money. A development-first project that turns out to have needed configuration produces custom code in your database that has to be maintained, breaks at upgrades, and is politically hard to delete because someone paid for it. The second failure is worse and it’s permanent.

But I can’t fully separate that reasoning from my commercial interest in it, and you shouldn’t assume I have. What I’d suggest is testing it cheaply: spend an afternoon in a demo database on the specific thing you think needs building. If Odoo already does it, you’ve learned something for free and you know which consultant to call.

What to take away

Functional and technical Odoo consultants solve different problems, and buying the wrong one produces a predictable failure. Custom code for something native, or an elaborate configuration workaround for something that needed forty lines of Python.

Ask whether your problem is a process question or a product limit. “How should we” is functional. “Odoo can’t, so how do we” is technical, provided someone competent verified the first half.

Most things described as needing development need configuration, so default to functional first and bring technical in once the gap is confirmed. The exception is integration and performance work, which are technical from the start.

And if you can find the functional consultant who reads code well enough to recognize the boundary, pay for them. Failing that, enforce one rule: no custom development starts until a functional consultant has confirmed the native gap.

If you're not sure which side of that line your problem sits on, book a call and we'll tell you, including when the answer is neither.

Book a Call

FAQs

Author

Hardik Soni

Hardik Sonii is the CEO and Sales Director at CodeTrade's official Odoo Partner operation in Dubai. He works across Odoo, AI/ML, Python, Django, and e-commerce, and has spent years helping businesses in the Middle East adopt technology that fits their scale and industry requirements.