Every Odoo project eventually produces a list titled something like “gaps”. Each line is a thing the business does that standard Odoo supposedly does not. Some of those lines are real. Many are habits from the old system wearing a disguise.
Deciding which is which is the single most important cost decision in an Odoo rollout, because every line you send to development becomes code you own for as long as you run the system.
Three layers before you write code
Odoo gives you three ways to change behaviour before anyone opens a Python file.
Settings and configuration. Routes, multi-step receipts, approval thresholds, pricelists, payment terms, fiscal positions, reordering rules. A surprising number of “gaps” disappear once someone who knows the current version walks through the settings screens. Odoo 17 and 18 in particular added options that used to require modules, such as more flexible approval flows and better barcode operations.
Studio and no-code changes. Odoo Studio (an Enterprise feature) lets you add fields, tweak forms and list views, build simple automations and design reports. It is ideal for adding a “customer PO number” field to sales orders or a required “reason” field on credit notes.
Automated actions and server actions. These trigger on record changes, such as notifying a manager when a quote exceeds a value or setting a default warehouse based on the customer’s region. They need some technical comfort but no custom module.
Only when a requirement survives all three should it become development.
The four-question test
For each line on the gap list, ask:
- Does this process create a competitive advantage, or is it just how we’ve always done it? A unique pricing model that wins deals is worth coding. A five-step approval chain for $200 purchases probably isn’t.
- What breaks if we adapt to standard? Be concrete. “The warehouse team will need to scan twice” is a real cost. “People are used to it” is a training problem.
- How often does it happen? A once-a-year process can live in a spreadsheet beside Odoo. A thousand-times-a-day process cannot.
- Will it survive an upgrade? Changes that override core methods or alter standard views heavily tend to break every year. Changes that extend models with new fields and hooks usually don’t.
If a requirement scores high on advantage, frequency and cost-of-adapting, build it. If not, change the process.
Where customization earns its keep
Some requests are clearly worth the investment:
- Industry calculations that Odoo doesn’t model, such as fat- and SNF-based milk payments, catch-weight pricing in meat processing, or yield tracking across multi-stage food production.
- Integrations with carrier systems, marketplaces, legacy machines or government e-invoicing portals that lack ready-made connectors.
- Operational shortcuts for high-volume roles: a one-screen dispatch board, a custom picking sequence, a route optimization tool for delivery fleets.
- Customer-facing portals that need behaviour the standard portal doesn’t offer.
These are cases where good Odoo customization services pay for themselves within months, because the alternative is staff time spent on workarounds every day.
Where it usually doesn’t
Reports that replicate the old system’s layout pixel by pixel. Renaming standard fields to match legacy terminology. Approval steps nobody can explain. Duplicating features from an app you haven’t licensed yet, when licensing it would be cheaper than building it.
One honest caveat: adapting to standard is not free either. It costs change management, and some teams genuinely lose efficiency for a few weeks. That cost is temporary. The maintenance cost of an unnecessary module is not.
Writing customizations that age well
When something does need code, a few rules keep it upgrade-friendly:
- Put every change in its own module, never in edits to core files.
- Inherit and extend rather than override; call
super()so standard behaviour still runs. - Prefer XPath view inheritance that targets stable anchors like field names over position-based selectors.
- Keep business logic out of views and reports.
- Write at least basic automated tests, so the next upgrade shows you exactly what broke.
The Odoo developer documentation covers inheritance patterns in detail and is worth sharing with anyone writing modules for you, even if they insist they already know it.
The takeaway
Treat every customization request as a small investment decision with a yearly maintenance fee attached. Configure first, use Studio second, code third. Projects that follow that order go live faster and cost less to upgrade, and the code they do carry tends to be the code that matters.
