Odoo · consulting and configuration

Your Odoo is installed.
It is not working for you yet.

Going live is not the same as putting it to work. Half the apps are asleep, data is entered twice, and a spreadsheet is still running alongside. I take over the existing configuration and make it serve what you sell.

Odoo 19 Community & Enterprise Odoo.sh On-premise

The starting point

Many installations
stop at go-live

The integrator delivered, the invoice has been paid, the users learned on the job. Two years later, the accounting runs, the rest much less so: quotes are reworked by hand, stock levels are wrong, purchasing is decided outside the tool, and every department has rebuilt its own file on the side.

It is almost never a software problem. It is a configuration laid over an organisation that has changed since, or that was never decided in the first place. Odoo can do a great deal — provided someone tells it what to do, in which order, and under which rules.

That is where my work starts: on an existing database, with your real data and your real habits. Not on a demo instance.

An app nobody decided to use is not asleep: it produces wrong data that someone will correct by hand.

On your instance

What I actually do

Nothing that requires touching the code. Standard Odoo, properly configured, covers more ground than people think — and whatever it covers, it keeps through version upgrades.

Audit
What is useful, what gets in the way, what costs money, what is asleep. Which standard apps to switch on, which to switch off, and where the current configuration contradicts what the teams actually do. It is the first deliverable, and it sometimes concludes that there is not much to do.
Configuration
The sequence of steps, business rules, access rights, approvals. Who sees what, who approves what, and at what point a document becomes binding.
Automation
Scheduled actions, automation rules, email templates, deadline alerts — without a line of code. That is what gets rid of manual follow-ups and the Monday-morning exports.
Data
Structuring and migrating the reference data: what a customer, a product or a site actually is, in your organisation. Vague reference data produces reports nobody believes.
Trade-offs
Between standard configuration and development, the standard almost always wins. Custom development is paid for twice: once when it is written, then again at every version upgrade.

Transparency

What I do, and what I pass on

A clear boundary is worth more than a broad promise. It avoids the project that gets bogged down with a provider working outside their field.

I do
Functional configuration and day-to-day administration, no-code automations, installation and maintenance of my own modules, and scoping — including the scoping of what I will not deliver myself.
I delegate
Version migrations and custom development outside my modules. A partner takes them on, and I remain your point of contact: I scope the work, I oversee acceptance testing, and I keep responsibility for the business outcome.
I don't do
Reselling Odoo licences. I take no commission on them, so none of the advice I give you on Community or Enterprise is self-interested.

Case study

One signed quote,
eight apps that follow

Modular building · Odoo · 12 users

CMI

What I did

The CRM repurposed to track quotes to be produced rather than prospects, then a single trigger: signing the quote creates the project, the purchase requests and the manufacturing orders, and delivery triggers the invoice.

What remains

The whole job run from the project record, and its margin on a single dashboard — within standard configuration, without a single line of custom development.

Publishing

I also publish my own modules

When the tool does not exist, I write it. It is also what guarantees that the person configuring your instance understands what they are installing in it.

The core is modular, and that is not a sales argument: a vertical layer never leaks back into the generic layer. A maintenance contractor therefore does not install what does not concern them, and the price follows what is installed.

PostGIS is optional. The core runs on PostgreSQL alone, and that is the default installation mode — it is this constraint that makes the modules installable on hosting I do not control, yours for instance.

If you are an integrator looking for a mapping component to deploy for a client, that is also a conversation I have regularly.

See the two software products I publish →

Fit

Who this page is for

This is for you if

  • Odoo is already live in your organisation, and you sense the tool could do more.
  • Your integrator is no longer available, or no longer suited to what you have become.
  • The same information is entered twice, in two places.
  • You manage equipment or interventions in the field.
  • You are an integrator looking for a mapping component to install for a client.

This is not for you if

  • What you need is a version migration: that is delegated.
  • What you need is custom development outside my modules: that is delegated too.
  • You want to buy Odoo licences: I am not a reseller.
  • You do not have an ERP yet and the process is not settled. Start with process engineering.

Questions

What people ask me about Odoo

That is the most common case, and in fact the heart of the matter. The integrator delivered, the invoice has been paid, and two years later the configuration no longer matches the organisation. I take over what exists as it stands, with your real data and your real habits — not a demo database.
I work on both, and on Odoo.sh as well as self-hosted. The choice is not mine to make: I am not an Odoo licence reseller, so I have no interest in getting you to buy any. If standard Community is enough for what you need, I tell you so.
No. Version migrations and custom development outside my own modules go to a partner. I keep the scoping, the acceptance testing and responsibility for the business outcome — a clear boundary is worth more than a broad promise.
With an audit of the configuration, not with a change. What is useful, what gets in the way, what costs money, and what is asleep. The first deliverable is an assessment of where things stand, with the order in which to tackle the work — and it sometimes concludes that there is not much to do.
Then I say so. A configuration laid over an organisation that has not been decided only postpones the problem, at a higher cost. In that case the right way in is process engineering: we set the business rules first, and configure afterwards.

Let's take stock of your instance

Tell me your version, the apps in use and what is not working the way you would like. I reply within 48 hours with an initial view, including when your instance does not need any work.

Describe your instance →