Odoo ERP · Customisation
When to Customise Odoo, and When to Stay Standard
· Updated · 2 min read
Every custom module is something you retest on the next upgrade. That is not a reason to avoid code. It is a reason to spend it on the process that would otherwise stay in a spreadsheet forever.
Configure first
Taxes, warehouses, pricelists, approval routes, and studio-free settings cover more than a first workshop suggests. Change those before you commission a module. The sequence is step three of the implementation guide.
A field that only one report needs can often be a standard property or a note. A field that warehouse staff must fill on every receipt is a real requirement.
Build when the workaround is permanent
If people will keep a side file for approvals, batch numbers, or a customer-specific price that Odoo cannot express, write the code. A workaround that lasts a week is fine. A workaround that is the process is a defect.
Put that work through customisation: a short spec, a staging test, and a note about what the next upgrade must retest. Code without a spec becomes a surprise in user acceptance testing.
Studio and modules are different tools
Studio is useful for a field, a view, or an approval on Enterprise. A new document flow, a heavy report, or an integration belongs in a module your team can read in git. The comparison is in Studio vs custom modules.
Do not let a demo audience add fields live on production. Those changes are hard to review and easy to lose.
Budget the maintenance, not only the build
Customisation moves an India implementation up the range in the cost guide. The later cost is the retest when you migrate versions.
Keep a list of customisations with an owner. If nobody can explain why a module exists, it is a candidate to remove before the next upgrade.
Frequently Asked Questions
Is custom code a failure of the standard product?+
No. Odoo is meant to be extended. The failure is building before the standard flow has been tried on your own data.
Will custom modules block an upgrade?+
They have to be reviewed and retested. Modules that use stable extension points usually move. Unreviewed overrides are the ones that stall a project.
Can we add fields ourselves?+
On Enterprise, Studio can add simple fields. Agree who is allowed to change production views so the database stays reviewable.