Odoo is a massive ecosystem. The number of ready-made modules, apps, and built-in features is huge — from advanced production scheduling, through automated warehouse rules, to multi-currency accounting.
And yet, the same scenario keeps playing out at many companies: a need for a new feature comes up in a meeting, and the first thing someone says is: "Let's write a dedicated module for that."
That's an easy trap to fall into. A lack of deep familiarity with the Odoo standard leads companies to pay thousands for coding solutions the system already has... in its standard configuration.
A real-life example: how forgotten custom "ribbons" saved the budget
I recently sat in on a standard client meeting where we were scoping a task for the shop and product view. The client needed the template modified so certain items would show a clear notice about limited availability.
The system already had some tags and badges showing other product attributes, but adding another one would have meant rebuilding the template and writing custom code. Before we could even estimate the developer hours, there was a great plot twist.
While reviewing the system, it turned out the client already had custom Product Ribbons built, automatically overlaying the product thumbnail in the shop — nobody at the company just remembered they existed. The feature had been built during an earlier project and was never documented, so over time it simply faded from the team's memory.
The result? Zero extra code, zero money spent on developers, zero extra risk on future upgrades. All it took was turning on and configuring something that had already been sitting in the system the whole time.
Three consequences of ignoring Odoo's standard features
When we skip a thorough analysis of what the system can already do and jump straight to writing our own modules, sooner or later we run into three problems:
- 1. Fighting the system's architecture ("working around it") Odoo was designed around specific business logic. When we write code against that logic, we turn a flexible system into a cumbersome tool. Instead of a smooth flow of data, you get workarounds, extra clicks, and processes that need to be manually babysat.
- 2. Team frustration and the myth of "inefficient Odoo" When a poorly configured system, overloaded with custom code, starts to choke, a narrative takes hold in the company: "This system can't do anything." In reality, it isn't Odoo that failed — it's the way someone tried to force a simple task into it.
- 3. Growing technical debt and coding under time pressure Writing custom code in a rush, under the pressure of an approaching go-live date, almost always hurts quality. Code like that is rarely fully tested, and worse, it often drifts away from Odoo's own development standards. I've already written about how excess unnecessary code can paralyze an entire process, using a concrete example from an order-shipping workflow.
The cost of writing the code is only the beginning
The biggest mistake management makes is looking at custom module development purely through the lens of the developer's first invoice.
The cost of writing the code is just the tip of the iceberg. The real cost shows up later, in maintenance, migrations, and missing documentation.
Every line of custom code in Odoo carries concrete financial and operational risk down the line:
- The documentation trap and vendor lock-in: In my own development work, I very rarely come across full, reliable documentation for custom modules. Knowledge of how that code works, why it was built, and how to use it, ends up living only in the heads of a few people at the implementation company. When, down the line, you want to switch IT partners or take over system maintenance yourself, the new person has to spend dozens of billable hours "guessing" what the original developer meant.
- Official tutorials vs. a "black box": For Odoo's standard features, the vendor maintains rich documentation, official manuals, video recordings, and step-by-step tutorials. A new employee in the warehouse or the office can learn the standard in a few minutes. With sprawling, undocumented custom code, onboarding every new team member turns into a nightmare.
- More expensive, more complicated migrations: Odoo ships a new major version once a year. The more custom scripts you have in your database, the more budget gets eaten up rewriting and refactoring them when you move to a newer edition.
- Ongoing servicing and fixes: Custom code needs constant attention — updating whenever the PostgreSQL structure changes, and adapting whenever the company's processes change. I wrote more about how to approach the structure of custom modules in this post about technical debt in Odoo.
The "Standard First" rule – how to do it right
Before deciding to write even a single line of custom Python code, the analysis process should follow a clear hierarchy:
- Standard Odoo configuration: Can this be done using existing settings, automation rules, or built-in UI elements like product ribbons?
- Modules from the OCA (Odoo Community Association) community: Has this problem already been solved and tested by thousands of developers worldwide, as a proven, free open-source solution?
- No-code modifications (Odoo Studio): Is a simple view change or a new field enough, without touching the underlying database architecture?
- Dedicated code (custom development): Only once the above options fall short, and the business requirement offers a genuine competitive edge, do we sit down to write a custom module — and write its documentation at the same time!
Summary
Writing custom modules in Odoo is a great option, but it should be a deliberate last resort, not the first choice. A good developer doesn't measure their worth by the number of lines of code they write, but by how well they can put the system's existing potential to work, without steering the company into a dead end of undocumented code.
Before you commission a new feature, make sure you're not paying to reinvent the wheel.
Looking for a way to optimize your Odoo?
Want to check whether your system is using the full potential of its standard features, or is weighed down with unnecessary, undocumented code? Book a consultation — I'll run an audit and show you where it's actually worth writing code, and where the standard is enough.