Short answer: Odoo Studio is Odoo’s low-code layer for changing fields, screens and automations without programming. Tempting, but we are deliberately cautious with it. On version upgrades, Studio changes regularly break - fields disappear from views, inherited views get reset - and combined with custom code it almost inevitably leads to faults that are hard to localize. For anything that genuinely matters, we prefer customisation you can isolate and switch off.
What Odoo Studio promises
Studio is appealing, and we get it. You do not have to wait for a developer, you quickly add a field yourself, adjust a screen or build a small automation. For small, isolated things that is fine. We are not against Studio; we are against Studio as the default answer to every wish.
Because the story does not stop at “it works today”. An ERP system has to last for years, and that is exactly where it pinches.
Where it goes wrong: the upgrade
Odoo ships a new version every year. Changes you make in the interface on top of the standard views do not always survive such an upgrade. In practice we see it as fields that have suddenly disappeared from a view, or inherited views that were reset to standard on the upgrade.
The result: after the upgrade your freshly configured screen looks different, and you have to rebuild it by hand. Right at the moment you are already busy with the upgrade itself, and without a clean record of what was there. That is not an incident, it is a recurring pattern.
Even riskier: Studio plus custom code
It gets genuinely dangerous when Studio and custom code live side by side. Studio changes the view in the database, custom code changes things in code, and the two layers do not know about each other.
On a fault you then cannot tell whether it is Studio, the custom code, or the clash between the two. Those are exactly the faults that cost hours to find, because there is no single place to look. The more Studio changes sit on top of a custom implementation, the more opaque the whole thing becomes.
Why we prefer custom development: you can switch it off
The biggest advantage of a clean custom module is simple: you can isolate it. If something breaks, you switch the module off. Does it work again? Then you know where the fault sits. Still broken? Then it is somewhere else.
That off/on test is invaluable for localizing faults, and it is exactly what you cannot do cleanly with Studio changes woven into the database. On top of that, custom code lives in version control, can be tested against a new Odoo version before the upgrade, and shows you exactly what changes. That is not a luxury; it is the difference between a manageable system and a system nobody dares to upgrade anymore.
| Odoo Studio | Custom development (module) | |
|---|---|---|
| Change something small fast | Strong | Slower |
| Behaviour on upgrades | Breaks regularly (fields gone, views reset) | Tested, in version control |
| Isolatable on faults | No, woven into the database | Yes: switch off, fault localized |
| Combining with custom code | Risky, hard to debug | One consistent codebase |
| Long-term maintenance | Unpredictable | Manageable |
When Studio is fine
Honestly: Studio is not the devil. An extra field on a non-critical model, a quick prototype to show an idea, a small standalone automation. For that kind of small, isolated thing Studio can work fine, as long as you accept you may have to check it after an upgrade.
The line sits at two things: business-critical, and the presence of custom code. As soon as one of those comes into play, Studio’s speed no longer outweighs the risk.
Our rule of thumb
Use Studio as little as possible, and never for anything business-critical or in combination with custom code. As soon as it matters, or as soon as custom code is already nearby, choose customisation you can isolate, test and switch off.
That is not dogma against low-code; it is hard-learned from upgrades and faults. Odoo Studio is rarely the solution. Often it is the start of the problem.
Frequently asked questions
Is Odoo Studio bad? No, not bad, but we are deliberately cautious with it. For small, isolated changes Studio can work fine. The risk is in the pattern: on upgrades Studio changes regularly break, and combined with custom code it leads to faults that are hard to localize.
Do Studio changes break on an Odoo upgrade? Yes, regularly. We see fields disappear from a view and inherited views reset to standard on the upgrade. Your freshly configured screen then looks different and has to be rebuilt by hand, right during the upgrade.
Odoo Studio or custom development? Small and isolated, on a non-critical model: Studio can do it. Business-critical, or alongside existing custom code: choose custom development. A custom module can be isolated, tested against a new Odoo version and lives in version control, so you know exactly what changes.
Can you combine Odoo Studio and custom code? Technically yes, but it is risky. Studio changes the view in the database, custom code changes it in code, and the two layers do not know about each other. On a fault you then cannot tell whether it is Studio, the custom code, or the clash between them. Those are the faults that cost hours.
What do you do when something breaks? With custom development we simply switch the relevant module off to see if the problem disappears. If it does, you know where the fault sits. That off/on test is invaluable for localizing, and you cannot do it cleanly with Studio changes woven into the database.
Want a system that is still upgradable in three years?
That is exactly what we steer for: changes you can isolate, test and roll back, instead of invisible edits that produce surprises on every upgrade. More on that trade-off in Implementing Odoo directly or through a partner and our implementation method. Want to talk it through for your situation? Book a free intro call.