Odoo Studio vs Custom Code: Where to Draw the Line
What Odoo Studio does well, where it creates trouble, and when to switch to custom module development. A practical decision guide with examples.
Odoo Studio lets non-developers add fields, change views, build simple apps and set up automations, all through the browser. It's genuinely useful. It's also easy to overuse.
What Studio is good at
- Adding fields to forms and lists, such as a "Customer PO reference" on sales orders
- Rearranging views: moving fields, hiding ones nobody uses, adding tabs
- Simple reports: tweaking document layouts
- Simple automations: send an email, set a field, create an activity when a condition is met
- Small standalone apps, like an equipment register or a request log
For these, Studio is faster and cheaper than a developer, and the business can make the changes itself.
Where Studio gets risky
- Complex logic. Multi-step calculations, validations across several models, conditional behaviour. Automated actions with Python code work, but they're hard to test and review.
- Many interdependent automations. Five automations firing on the same record update, in an order nobody can quite explain.
- Performance-sensitive changes, like computed fields on large tables.
- Integrations. Anything talking to external systems belongs in code with proper error handling.
- Changes nobody documented. Studio makes changes easy to make and easy to forget.
A simple decision guide
| Requirement | Use |
|---|---|
| Add a field, show it on a form or report | Studio |
| Hide or rearrange fields | Studio |
| Simple notification or activity | Studio automation |
| Validation involving one or two fields | Studio, carefully |
| Logic spanning several models | Custom module |
| Anything financial or stock-affecting | Custom module, with tests |
| Integration with another system | Custom module |
| Changes that need code review and version control | Custom module |
Govern Studio use
If you allow Studio, set a few rules:
- Only named people use it, and changes are logged somewhere
- Test in staging first, especially before an upgrade
- Review quarterly: remove fields nobody uses
- Name fields clearly so they make sense in exports and reports
Upgrades
Studio customisations are generally carried through upgrades by Odoo's upgrade service, but they still need testing. Python code in automated actions is the part most likely to break.
Our approach
We use Studio for the light stuff and custom modules for anything with business logic. We also teach key users to use Studio safely, so they're not waiting on a developer for every small change.
See Odoo custom module development for the coding side, or our Odoo customization service.
Frequently asked questions
Is Odoo Studio available in Community?
No. Studio is part of Odoo Enterprise.
Can Studio changes be moved to a custom module later?
Yes. Studio customisations can be exported as a module, and a developer can rewrite them cleanly. It's easier when Studio use has been modest.
ERP Builders Team
Articles written and reviewed by the ERP Builders delivery team — functional consultants, solution architects and developers who implement, integrate and support ERP systems.
Related articles
Odoo 20 Access Rights: Migrating to ir.access
Odoo 20 removes record rules and merges them into access rights with domains. What changed, how to migrate ir.model.access.csv and ir.rule, and what to test.
Odoo Custom Module Development: Practices That Last
How to build Odoo custom modules that survive upgrades: inheritance, module structure, security, testing, performance and code review practices.
3D Warehouse Management: Visualising Stock in 3D
What 3D warehouse management offers: bin occupancy views, slotting decisions, space planning, and how to build a 3D view on ERP location data.
Next step
Turn the plan into a working system.
Book a consultation with an ERP consultant. No sales script — just an honest look at your situation.