Odoo Studio vs custom code — when to use which
Studio is brilliant for the right job and a slow trap for the wrong one. We use both Studio and custom code on every client project — this post is the framework we use to decide which goes where.
Odoo Studio is the low-code customisation layer that lets you add fields, build screens, design reports and wire automations without writing Python. It is genuinely useful — and genuinely abused. Most of the technical debt we are asked to clean up is Studio sprawl that grew unchecked.
We are not anti-Studio. Used with discipline it accelerates delivery, empowers business users and keeps small customisations out of the development backlog. Used without discipline it produces undocumented logic, brittle upgrades and a configuration that nobody understands by year three.
This article is the rule of thumb our consultants apply: where Studio wins, where custom code wins, where the line moves with team maturity, and how we govern the boundary across our own customer base.
Where Studio is the right answer
Studio is at its best for small, additive, well-bounded changes that map cleanly to existing Odoo concepts: a few extra fields, a tweaked view, a custom report, a simple automation. These are the changes that would otherwise sit in a backlog for weeks.
We push hard for Studio in these cases. It puts the customisation in the right hands (the business user closest to the need) and keeps the dev team focused on the changes that genuinely require code.
- Add a few custom fields to existing models
- Reorder or rename fields in an existing view
- Build a small custom report or print template
- Wire a simple automation (status change → email)
- Create a lightweight new model for an internal use case
Where custom code is the right answer
Code wins whenever logic gets complex, reuse matters, the change touches multiple modules, or the integration surface is non-trivial. Anything you would want covered by tests, code-reviewed, and version-controlled belongs in a real module.
If a Studio change becomes hard to explain in one paragraph or hard to reproduce on a sandbox, it has outgrown Studio. Refactoring it into a module early saves you from a much harder refactor later.
- Logic that spans multiple models or modules
- Integrations with external systems beyond simple webhooks
- Anything that needs unit or integration tests
- Performance-sensitive code paths (batch jobs, reports on large data)
- Any change you would not want a junior to alter without review
The grey zone — and how to keep it tidy
Some changes start as Studio and quietly outgrow it. The common smell is when one Studio automation triggers another Studio automation, or when fields added in Studio start showing up in custom reports. That is when we draw a line and migrate the change into a code module.
The discipline is not 'never use Studio for x'; it is 'when Studio change y crosses threshold z, promote it to a module'. Document the threshold once and you stop having the same argument every quarter.
- Studio automation chained to another Studio automation
- Studio fields used in non-trivial custom reports
- Studio logic that needs to be deployed to multiple databases
- Anything a key user is afraid to touch
- Customisation that has become a single point of failure
Governance — the missing piece on most projects
Studio without governance produces Studio sprawl. Every project we audit has at least one undocumented Studio change from a power user three years ago that nobody dares touch. Avoid this by setting a small but real governance bar from day one.
Governance does not mean bureaucracy — it means a shared register, a quarterly cleanup, and an explicit owner for Studio changes per module. Half a day per quarter is enough to stay sane.
- Maintain a Studio change register per module
- Name an owner per module who reviews Studio changes
- Quarterly cleanup pass on Studio sprawl
- Document each Studio change in a one-line description
- Test Studio changes on sandbox before applying to production
The threshold rule we use at Flydoo
Our internal rule is simple: if a customisation touches more than two modules, has any conditional logic beyond a single 'if', or needs to be deployed to more than one database — it belongs in code. Otherwise Studio is fine.
- Touches more than two modules → module
- Has more than a single conditional → module
- Needs to be deployed to several databases → module
- Needs tests → module
- Otherwise → Studio is the right answer
Studio mistakes we keep cleaning up
Five patterns we find in almost every audit.
- Building business-critical workflows in Studio with no register or owner.
- Chained Studio automations that nobody can debug end-to-end.
- Deploying Studio changes manually across databases instead of as a module.
- Treating Studio changes as 'free' — no testing, no review, no documentation.
- Promoting Studio changes to code only after they break in production.
How to measure that the boundary is healthy
Numbers we track per module on customer projects.
- Number of Studio changes per module — should plateau, not grow forever.
- Studio change register completeness — every change documented.
- Number of Studio-to-code promotions per year — small but non-zero.
- Time to debug a Studio-related incident — bounded, not 'we don't know'.
- Number of undocumented Studio changes — should be zero after the first cleanup.
How we run Studio governance at Flydoo
Every customer project starts with a one-page Studio policy: who can change what, what gets registered, and the promotion threshold from Studio to code. We co-own the register with the customer's IT lead and review it quarterly.
When a Studio change crosses the threshold we plan the promotion to a module as part of the next sprint. We never let a chain of Studio automations grow to the point where one of us is the only person who understands them.
- One-page Studio policy on every project
- Studio change register co-owned with the customer's IT lead
- Quarterly Studio review meeting on the calendar
- Promotion to code planned as soon as a change crosses the threshold
- Knowledge sharing — never let one person be the sole expert
Before you greenlight a Studio change
Walk this short list before clicking save in Studio.
- Change is described in one paragraph
- Owner per module identified
- Change tested on a sandbox first
- Entry added to the Studio register
- Threshold rule applied — under threshold, Studio; above, plan a module
- Backout plan documented for non-trivial changes
- Quarterly review date in the calendar
Studio and code are partners, not rivals
Studio is the right answer for the right kind of change. Custom code is the right answer for the rest. The teams that win pick deliberately, document their choices and review the boundary regularly.
If you find yourself cleaning up Studio sprawl, it is not Studio's fault — it is the absence of governance. Set up the policy, the register and the quarterly review and the tool starts paying back again.
We are happy to do a one-day Studio audit on any production Odoo and tell you which changes should stay, which should be promoted, and which should be retired.
Frequently asked questions
Is Studio considered 'production-grade'?
Yes — Odoo officially supports Studio for production use. The risk is not the tool; it is undocumented sprawl. Used with a register, an owner and a threshold rule, Studio is a perfectly legitimate part of a production Odoo.
Will Studio changes survive an upgrade?
Most do, but some break. Always test Studio changes on a sandbox upgrade before pushing them to production. Studio changes that touch deprecated fields or removed views need to be reviewed at every minor release.
Can I version-control Studio changes?
Studio changes live in the database, not in a Git repo, so they are not version-controlled the same way as a module. You can export them and track the export, but the cleanest path for serious governance is to promote critical changes to a code module.
Who should own Studio in our team?
Pick a power user per module who knows the business deeply. Pair them with a developer for the harder changes. Without a named owner, Studio decisions become 'whoever is closest to the keyboard' and the sprawl starts.
How do I know when to migrate a Studio change to a module?
Apply the threshold rule: more than two modules touched, more than a single conditional, needs to be deployed to multiple databases, or needs tests — promote it to a module. Otherwise leave it in Studio. Keep the rule visible so the conversation is short.
Want to discuss what this means for your own Odoo project? We're happy to talk.