Customizing Odoo
Customising Odoo is easy. Customising it well — so it survives upgrades, doesn't break the next consultant who looks at it, and doesn't quietly double your TCO over five years — is a different sport. We've inherited enough heroic-but-unmaintainable Odoo customisations to know the rules that matter. This guide is the playbook.
Most Odoo customisation regret traces back to one of three decisions: Studio used where a custom module was needed, custom code used where Studio would have done, or worst — both used together with no clear owner.
Get the choice right and Odoo will adapt to your business beautifully. Get it wrong and every yearly upgrade will become a small archaeology project. The decision rules below are how we keep our clients in the first camp.
The three customisation tools you actually have
Odoo gives you three real customisation paths: configuration (no code, ships with the product), Studio (low-code, ships with Enterprise), and custom modules (Python + XML, written by a developer). They differ in cost, longevity, upgrade-friendliness and what they're appropriate for. Most teams underuse the first two and overuse the third.
There's a fourth path many forget: the OCA (Odoo Community Association) module catalogue. Hundreds of community modules cover common needs that would otherwise be custom dev. We use OCA modules every week — well-chosen and well-maintained, they're a free lever.
- Configuration: built-in fields, settings and rules — no code, no upgrade risk
- Studio: low-code field/form/report customisation — Enterprise only, mostly upgrade-safe
- Custom modules: Python + XML — fully flexible, owned by you, real upgrade work
- OCA modules: free, community-maintained, mixed quality — vet before installing
- Workflow automation: covered by Odoo Automations + Studio for most needs
Studio — when it's the right answer (and when it isn't)
Studio is brilliant for additive, local, low-stakes changes: a new field on a sales order, a custom view for the warehouse team, a small report tweak. It's stored in the database, survives most upgrades, and any Odoo consultant can read it. For the right use cases, Studio saves weeks of developer time.
Studio is the wrong answer for business-critical logic, complex calculations, integrations with external systems, or anything that needs proper testing. We've seen €40k of Studio 'rules' that should have been a €15k custom module — harder to debug, harder to upgrade, and impossible to peer-review.
- Use Studio for new fields, simple views, simple reports, simple automations
- Use Studio when the change is local and won't be reused across modules
- Don't use Studio for business-critical calculations or external integrations
- Don't use Studio for anything that needs unit tests — there are none
- Document Studio changes in your project wiki — they're invisible from Git
Custom modules — when they're worth it
Custom modules are the right answer when the change is structural, reusable, business-critical, or needs to integrate with anything outside Odoo. Examples we build regularly: industry-specific pricing engines, EDI integrations, customer portals with custom logic, reporting modules that aggregate across companies. Done well, they survive upgrades for years.
The cost is real: budget €5-50k per custom module depending on scope, plus 10-30% of that figure annually for upgrade and maintenance. The rule we apply is 'twice'. If a request will be done by more than one person, more than once a week, on more than one screen — it's a custom module candidate. Otherwise, Studio.
- Use custom modules for structural, reusable, or business-critical logic
- Use them for any non-trivial integration with external systems
- Always with proper Git, code review, automated tests — no exceptions
- Budget 10-30% of build cost annually for upgrade and maintenance
- Avoid the 'one giant custom module' anti-pattern — split into focused modules
OCA modules — the underused free lever
The OCA (Odoo Community Association) maintains hundreds of community modules covering needs that would otherwise be custom dev. Many are production-grade and used by thousands of companies. They're free, open source, and well-maintained for the most popular ones — but quality varies and you must vet before installing.
Our rule: check OCA before quoting any custom module. Roughly one in three custom requests has a credible OCA equivalent that gets you 80% of the way for free. The other 20% is often acceptable, or a small extension. We treat OCA as a first-class citizen of every customisation discussion.
- Check OCA before quoting any custom module — saves money one time in three
- Vet OCA modules: check last commit, maintainer, version compatibility
- Stick to widely-used OCA modules — the long tail is risky
- OCA modules can be extended (inherited) — you don't fork, you wrap
- OCA upgrade lag is real — verify a module supports your target version
Upgrade-friendliness — the real cost of customisation
Every customisation has an upgrade tax. Configuration is free. Studio is mostly free (occasional fixes per upgrade). OCA is moderate (depends on community release timing). Custom modules cost real money per upgrade — typically 10-25% of the original build cost, depending on how cleanly they were written and how much Odoo's underlying APIs have changed.
The teams that suffer most at upgrade time are those who skipped code review, skipped tests, and hard-coded against internal Odoo classes instead of public APIs. The teams that breeze through upgrades are those who treated their custom modules with the same engineering discipline they'd apply to any production code.
- Configuration: 0% upgrade cost — always free
- Studio: ~5% upgrade cost — mostly free, occasional manual fixes
- OCA: ~10-20% upgrade cost — depends on community release timing
- Custom modules: 10-25% of original build per upgrade — proportional to discipline
- Test coverage and code review at build time predict upgrade cost more than anything else
Customisation mistakes we keep cleaning up
These are the patterns that turn manageable Odoo into expensive Odoo.
- Using Studio for business-critical pricing logic — invisible from Git, untestable, brittle.
- Writing a custom module for a 5-line change Studio could have done in 10 minutes.
- Ignoring OCA — paying €15k for what a free, mature community module already does.
- Customising on a junior consultant's first project, with no code review or test coverage.
- Building one giant custom 'utils' module instead of small, focused, single-purpose ones.
How to measure if your customisation strategy is healthy
Markers we look for after a year of operation.
- Custom code share under 15% of total Odoo footprint — predicts low upgrade cost.
- Studio changes documented in wiki — every Studio change has a one-line note.
- Test coverage on custom modules above 60% — protects upgrades and refactoring.
- Time-to-upgrade to next yearly version under 4 weeks — proxy for discipline at build time.
- OCA module count similar to or higher than custom module count — signals discipline.
How we approach customisation at Flydoo
Our default is 'configure first, Studio second, OCA third, custom last'. We document every customisation decision with a one-page rationale explaining why we picked the approach we did. Custom modules go through Git, peer review, automated tests on every commit. Studio changes are logged in the project wiki with a screenshot.
We tell clients no when a request would be expensive to maintain — and we offer the cheaper alternative. Roughly two out of three custom requests get re-routed to Studio, OCA, or a process change. The third one becomes a properly engineered custom module.
- Default order: configure → Studio → OCA → custom — explain any deviation
- Every customisation has a one-page rationale documenting why this approach
- Custom modules: Git, peer review, automated tests, no exceptions
- Studio changes logged in wiki with a screenshot — visibility matters
- We say no to expensive customisations and offer the cheaper alternative
Practical customisation checklist
Tick most before approving any custom development.
- Configuration alone has been ruled out with evidence
- Studio has been considered and ruled out for a real reason
- OCA has been searched — no equivalent module exists or works
- Business owner can explain the change in one paragraph without jargon
- Estimated upgrade cost over 3 years has been included in the budget
- Custom module will live in Git with peer review and tests
- Documentation requirements are agreed before development starts
Key takeaways
- Customisation hierarchy: configure → Studio → OCA → custom — in that order
- Studio is great for local low-stakes changes, dangerous for business-critical logic
- OCA modules are an underused free lever — check them before quoting custom
- Custom modules cost 10-25% of original build per yearly upgrade — budget it
- Test coverage and code review at build time predict upgrade cost more than anything
Frequently asked questions
Should I use Studio or a custom module?
Studio for additive, local, low-stakes changes — new fields, simple views, small reports. Custom modules for structural, reusable, business-critical logic, or any non-trivial integration. The fastest test: 'will more than one person, more than once a week, on more than one screen, depend on this?' If yes, custom module. If no, Studio is usually fine. The mistake is using Studio for things that need code review, tests, and Git — those things are not optional for business-critical logic.
What is OCA and should we use it?
OCA is the Odoo Community Association — a non-profit that maintains hundreds of community modules. Many are production-grade and used by thousands of companies; some are early-stage or abandoned. Yes, you should use OCA — but vet each module: check last commit date, version compatibility with your target Odoo, maintainer activity, and number of stars/forks. Roughly one in three custom requests has a credible OCA solution that gets you 80% of the way for free.
How much does customisation add to upgrade cost?
Configuration changes: nothing. Studio changes: a small fix per upgrade in 10-20% of cases. OCA modules: depends on community release timing, usually 10-20% of equivalent build cost per upgrade. Custom modules: 10-25% of original build cost per yearly upgrade, depending heavily on engineering discipline (Git, tests, code review, use of public APIs vs internal). The teams that breeze through upgrades are those that built well in the first place.
Can we self-customise without a partner?
Configuration and Studio: yes, with proper training. Many of our clients handle Studio changes themselves once they're trained. Custom modules: not without an in-house Python developer who knows Odoo's framework and conventions. The temptation to 'just have someone code it' usually ends with a custom module that breaks the next upgrade. If you're going to build custom code, treat it like any production code: Git, review, tests.
What's the most expensive customisation mistake?
Putting business-critical logic in Studio. It's invisible from Git, hard to peer review, untestable in automation, and harder to debug than equivalent code. We've seen pricing engines, tax calculations and approval workflows built in Studio that cost the company weeks of audit work and tens of thousands in repair. If the change matters, build it as a proper module. Studio is for the 5-minute additive tweak, not for the heart of your business.
Need help applying any of this to your own context? We're happy to talk.