Implementation
How much customization does your Odoo really need?
The biggest failure factor in ERP projects is rarely the technology, but customization nobody can maintain anymore. At the same time, too little adaptation is just as costly, only on a different bill.
Customization isn't a question of how much, but of on what. What sets your organization apart, you're allowed to build. What's only habit, you're better off adapting to the standard.
Every Odoo project ends up at the same point: the package does something just slightly different from what you're used to. There are then two answers. You adapt the system to the process, or you adapt the process to the system. Both are defensible, both cost money, and the wrong choice pays you back for years.
The commonly heard rule of thumb, "keep it as standard as possible", is only half right. It's true for processes you do that way out of habit, and nonsense for processes that set you apart or that keep you compliant with the law. Whoever mixes up the two builds either an unmanageable system, or a system nobody wants to use.
Below is where the line lies, what both extremes cost you in hidden ways, and how to keep it manageable.
When standard Odoo is enough
For a surprisingly large share of organizations, the answer is: more often than expected.
The basic processes are simply built in
Invoicing, CRM, inventory management, and standard sales workflows are mature functionality in standard Odoo. Quote to order to delivery to invoice, with stock movements and follow-up, that works as it should, without a single line of code involved.
Light adjustments aren't customization
Extra fields, adjusted report layouts, custom email templates, changed screen layouts, automated actions, and approval rules: this is configuration. It usually survives an upgrade without problems and needs no developer. Calling this "customization" makes the discussion unnecessarily heavy.
The question you should ask yourself
Do we do it this way because it sets us apart, or because we've always done it this way? With the second answer, adapting the process is almost always cheaper than adapting the system, and it also gives you a process that lines up with how the rest of the market works.
When adapting the system is wise
Three situations where "keep it standard" is the wrong advice.
Laws and regulations
Compliance isn't negotiable. Sector-specific reporting obligations, retention periods, accountability for who changed what and when, or requirements around e-invoicing and VAT treatment that differ in your sector. Here you don't adapt the process to the system, here the system has to do what the law says. Added benefit: this kind of customization is usually stable, because regulation changes more slowly than your business operations.
Integrations and specific standards
Your ERP rarely stands alone. EDI with a major customer, UBL and Peppol invoicing, integrations with carriers, machines on the shop floor, an industry-specific exchange format, or your accountant's system. Standard Odoo doesn't know those specific arrangements, and a manual in-between step is the most expensive solution here, precisely because it recurs every day.
Processes that are genuinely more complex
Some business operations don't fit a standard package, and that's not a shortcoming of the package. A pricing model with multiple tiers and customer-specific agreements, production with intermediate products that are themselves inputs for other orders, or a service process that runs differently per customer. If this is where your competitive edge lies, adapting that process to the standard is the same as giving away your advantage to save on implementation costs.
The ladder: five ways to get something done
Before you decide to build customization, work through this order. Every rung is more expensive to maintain than the previous one.
1. Configuration
Settings, fields, views, automated actions, report templates. Survives upgrades, needs no developer. Always start here.
2. An existing OCA module
Thousands of freely available modules from the Odoo Community Association, publicly maintained and kept up to date per Odoo version. If someone has already solved your problem, that's almost always the better route than building it yourself, since you then also share the maintenance with the community.
3. An OCA module with a small extension
If an existing module covers eighty percent, extend it instead of starting over. Keep the extension separate, so the original module can simply keep pace with new versions.
4. A module of your own
Where nothing exists, you build it yourself, as a standalone module, with its own name, its own tests, and its own owner. This is legitimate customization and it can work excellently, provided it's cleanly scoped.
5. Modifying the Odoo core
Don't do this. Whoever modifies the core itself disconnects from every future version and pays that back at every upgrade, every patch, and every security fix. Whatever the reason seems to be, there's almost always a route through rung four.
The hidden costs, on both sides
Both too much and too little customization come with a bill that arrives later. They just look different.
Too much customization: the upgrade becomes the problem
Odoo releases a version every year. Every custom module has to be checked, adjusted, and tested for it. With a handful of modules that's manageable; with dozens, an upgrade becomes a months-long project. Organizations that postpone that a few times end up stuck on a version that no longer receives support, exactly the situation they wanted to escape with a new ERP.
Too much customization: knowledge becomes scarce
The more custom your system, the smaller the group of people who can work with it. That makes you dependent on a few individuals or a single vendor, and it makes every change expensive. Undocumented customization whose creator has since left, nobody dares to touch anymore, so it stays in place, even once it no longer fits reality.
Too little customization: the work moves to the sidelines
This is the cost item that's almost never counted. If the system doesn't fit the work, the organization solves it itself: in spreadsheets alongside Odoo, in separate emails, in agreements that only exist verbally. Your processes then run outside the system, which makes your data incomplete, your reports incorrect, and the benefit of the ERP largely evaporates.
Too little customization: users drop off
A system that makes the work harder than it was loses its users. You notice that in half-filled fields, overdue data entry, and a growing number of colleagues who'll "update it later". An implementation that's technically successful but used by nobody has still failed, and those failure costs appear on no invoice.
The maintenance you have in both cases
Regardless of the amount of customization, fixed items remain: hosting, backups, monitoring, security updates, keeping modules up to date, and testing releases. Include those in your budget, even in the "we're keeping it standard" scenario. The costs get smaller with less customization, but they never reach zero.
Best practices
What keeps customization manageable is less a technical matter than a matter of discipline.
Start with the process, not the screen
First describe what needs to happen and why, before anyone decides what it looks like. Many customization requests disappear as soon as the question "why do we do it this way?" has to be answered.
Everything in separate modules, never in the core
One piece of functionality, one module, with its own name and a clear boundary. That turns an upgrade into a series of small checks instead of one big tangled mess, and it makes it possible to switch something off without affecting the rest.
Record why, not just what
Code tells you what happens; only documentation tells you why it had to be that way. Three years from now, that question is decisive in determining whether something is still needed. Record the reason, the owner, and the date for every piece of customization.
Review at every upgrade and dare to cut
Treat a version upgrade as a moment to clean up. Which customization is still used, which exception still applies, what has since become standard in Odoo? There's no cheaper maintenance measure than code you remove.
Test what you build
Automated tests on your own modules aren't a luxury with Odoo but the only way to keep an upgrade affordable. Without tests, every version jump is manual click-through checking; with tests, it's a matter of running them and seeing what turns red.
Assign an owner per piece of customization
Someone within your organization who can explain why it exists and who decides whether it stays. Customization without an owner naturally becomes customization nobody dares to remove.
The rule of thumb
Adapt the system where you set yourself apart or where the law requires it. Adapt the process where you were simply used to it. For everything in between, first work through the ladder, configuration, OCA, extension, and only then custom code.
If you're not sure where a specific request falls in that scheme, we're happy to look at it with you. We build customization where it pays off, and just as readily say when a process change delivers more value.
Schedule a strategy session →