Odoo Studio or Custom Code? How I Decide What to Build

It always starts small. A client asks whether we can add a field for the broker's commission, or make the delivery note show the driver's name, or hide three fields nobody on the sales team ever fills in. My honest answer is almost always yes — Odoo can do it. The real question I am answering underneath every one of those requests is not whether it is possible. It is whether I open Studio or open a code editor, because that choice, made carelessly enough times, is how a clean Odoo instance turns into something nobody wants to touch two versions from now.

What Studio genuinely handles well

Odoo describes Studio, in its own documentation, as a toolbox used to customise Odoo without coding knowledge — and for a real slice of what clients ask for, that is exactly what it is. Worth knowing before anything else: Studio ships only with Enterprise, and installing it on Odoo Online's Standard plan automatically triggers an upsell to the Custom plan, the same tier that unlocks multi-company and the external API. If you have not settled which edition you are running, that decision affects far more than Studio access.

Fields are the clearest case. Studio lets you add a field that does not exist yet, or pull an existing one onto any view — and because Odoo documents fifteen underlying field types, Studio fields are saved as real columns in your database, not some parallel layer bolted on top. Views work the same way: form, kanban, list, calendar, pivot, graph and half a dozen others are, in Odoo's words, simply different ways to show the same data, and Studio lets you rearrange what each one shows without touching XML.

Automation rules cover a surprising amount of what people assume needs a developer. Studio's automation rules fire on five kinds of trigger — a value changing, an email event, a timing condition, a record being created or edited, or an external event — with actions that include updating a record, creating an activity, sending an email, SMS or WhatsApp message, and adding or removing followers. Approval rules sit next to this: they gate a button behind a required approver before an action can run, which covers a lot of the "someone senior has to sign off first" requests I get. And the PDF report editor lets you drag fields, static or dynamic tables, images and banners onto an existing report layout, with values updating live as you build.

Where Studio stops

The honest limits show up quickly once you look past the no-code pitch. Two of Studio's own action types — Execute Code and Send Webhook Notification — are themselves a form of programming, so "no-code" is more of a spectrum than a promise; the moment an automation rule needs a code snippet or a webhook payload, someone who can write and test that code is already involved, Studio interface or not.

Reports have a similar ceiling. Odoo's own documentation says the conditions inside a report's conditional blocks can only be edited in the underlying XML, not the visual editor — and that editing a report's header or footer affects every standard and custom report built on it, not just the one you are looking at. That second point catches people out: a header tweak requested for one delivery note can quietly reshape every invoice, quotation and purchase order in the system.

Past that, you are into territory Studio was never meant to cover: real business logic with multiple conditional states, an integration that calls a third-party API, a calculation that has to be provably correct rather than approximately right. None of that is a criticism of Studio — it is doing exactly what a no-code layer is for. It just means the line between a quick Studio change and a proper custom module is narrower than most demos suggest, and I would rather draw it honestly before the build starts than discover it mid-project.

The decision flow I use

Rather than re-litigate this project by project, I run every request through the same three questions, in the same order. It sounds rigid, but it saves more arguments than it starts: most "customisation" requests turn out to be either something the standard app already does, or something Studio handles cleanly. What genuinely needs custom code is a smaller category than most people walk in expecting — and when I actually counted what gets built as custom modules across ten UAE implementations, accounting still outweighed every other app by a wide margin.

The hidden long-term costs

Where a change lives does not just affect this week's build. It changes what the next three years of that Odoo instance look like.

Upgrade fragility

This is where the two paths genuinely diverge, and it is backed by Odoo's own upgrade policy rather than my opinion. Odoo's upgrade service covers customisations built with Studio, provided Studio stays installed and the subscription stays active — because those changes are stored as structured data in your database, the same upgrade process that converts your standard modules converts them too. A custom-coded module does not get that. Odoo's developer documentation on upgrading a customised database is explicit that the module's own code has to be made compatible with the target version before the database can move, and that work is the client's or their partner's to do — it is not something the upgrade service performs. I go through what that compatibility work actually costs in a closer look at what a real Odoo version upgrade involves.

Who can maintain it

Most Studio work — a new field, an adjusted view, a straightforward automation rule — is something a trained administrator or functional consultant can maintain without opening a terminal. A custom module needs someone who can read Python, understand the ORM, and safely change code other parts of the system depend on. That is a staffing question to answer before you build, not after the person who wrote it has moved on.

Testability and how changes behave

Custom modules can live in version control, get reviewed, and be tested in a staging copy before anyone touches production — the same discipline you would want from any software change. Studio changes are made directly against the live database through a visual editor, which is what makes them fast, but it also means there is no built-in equivalent of a pull request. I get around that by keeping a written log of every Studio change outside Odoo, so there is at least a record of what changed and why.

Fit the standard first

My rule, after ten years of this, is to implement the standard app first and resist customising anything until I can say plainly why the business needs it. Much of what gets requested as customisation is really just unfamiliarity with how Odoo already does the job — and every hour spent rebuilding a standard screen to look like an old spreadsheet is an hour that did not go toward what actually differentiates the business. I break down where that budget typically goes in what actually drives Odoo implementation cost in the UAE.

Some businesses are the exception, and it shows in what earns a real module rather than a Studio patch. A bill-of-quantities estimate rolling into job costing and progress billing is genuinely how the engineering and contracting builds I run differ from a standard trading company, so I scope that as custom development rather than bending Studio around it. The same is true of milestone-based tracking and margin-guarded rate quoting in the freight-forwarding projects I build — that logic is the business, so it earns a proper module.

Frequently asked questions

Related reading

More from my desk: Odoo Community vs Enterprise — how to choose — the edition decision that determines whether you have Studio at all; what actually drives Odoo implementation cost in the UAE — where the Studio-versus-custom-module call shows up in your budget; and how to choose an Odoo implementation partner in the UAE — including the question I think every buyer should ask about what not to customise.