Every Odoo implementation faces the same tension: how much do you customise Odoo to match your existing process, versus how much do you adapt your process to match standard Odoo? The wrong answer in either direction is expensive. This guide gives you a decision framework.
Why Customisation Is Tempting
Business users naturally want the new system to “work like our current system, but better”. Every variation between standard Odoo and existing process becomes a customisation request. Partners often comply because saying yes is easier than saying no.
The Hidden Cost of Customisation
- Initial development cost (obvious)
- Testing burden — every customisation needs regression testing on every Odoo upgrade
- Knowledge concentration — customisations live in someone’s head and Git history
- Upgrade tax — heavily customised Odoo upgrades cost 3–10× standard upgrades
- Hiring friction — new partners and developers need ramp-up on your specific customisations
- Fragility — customisations often break in non-obvious ways when standard modules change
The Decision Framework
Customise When…
- Regulatory or compliance requirement that standard Odoo cannot meet (UAE-specific reports, industry-specific compliance)
- Genuine competitive differentiator in your process (rare — most “different” processes are just habit)
- Integration with critical external system (bank, payment gateway, marketplace)
- UI tweak that meaningfully reduces user error rates (e.g., field validation, mandatory fields)
Adapt Your Process When…
- Standard Odoo achieves the same business outcome via a slightly different workflow
- Your existing process exists only because legacy software forced it
- The “requirement” is preference, not necessity
- Standard Odoo is the industry-best-practice version of what you do manually
The “Why Three Times” Test
Before approving any customisation, ask “why?” three times:
- “Why do we need this customisation?” — usually “because that’s how we do it”
- “Why do we do it that way?” — usually “because the old system worked that way”
- “Why did the old system work that way?” — usually “because it had to”
If the answer to the third “why” is rooted in legacy constraints that no longer exist, the customisation may not be needed.
Customisation Types Ranked by Risk
| Type | Risk | Upgrade Impact |
|---|---|---|
| Studio configuration (no-code) | Low | Low |
| Server actions and automated actions | Low | Low |
| Custom report templates | Low-Med | Low |
| Custom field additions | Low-Med | Low |
| Inherit and extend standard modules | Medium | Medium |
| Override core ORM behaviour | High | High |
| Replace standard module entirely | Very High | Very High |
The Customisation Budget Discipline
One practice that works: at the start of implementation, allocate a customisation budget (typically 15–25% of implementation cost). Every customisation request is debited from that budget. When the budget is exhausted, additional customisations require explicit approval and re-budgeting. This forces conscious trade-offs instead of feature creep.
The Studio-First Discipline
For every customisation request, ask: “Can this be done in Studio?” If yes, prefer Studio over Python code. Studio configurations survive upgrades much more reliably than custom code.
Free 30-minute customisation review.