How to Choose Between Odoo 20 Studio and Custom Development

There will come a time when there is a need to add additional fields, additional approvals, and a screen to track something not possible in Odoo for the business. The question will be raised about whether to implement this functionality via Studio or via a custom module.

Each approach has its advantages and disadvantages. Studio is fantastic, but it gets untidy very quickly, and nobody wants to touch it on upgrading. Custom modules are great, but they can be over-engineered for a single checkbox. Let’s check out how to choose one or another approach.

Getting started

Odoo is an application that you use to run your business on a daily basis. The application is utilized for management of sales, invoices, inventory, and human resources, among others. Depending on the nature of the company, customization of the application will be done as follows:

• Studio: It is the built-in drag-and-drop system on Odoo. You have the flexibility to add new fields, design screen layout, and set basic conditions. It is just like decorating and furnishing your home.
• Custom Module: This is a set of code written by the programmer and installed in Odoo. This is more like an extension of the house.

This guide will help you make an informed decision on whether to opt for Studio or your own module. Below is the terminological analysis.

How Studio works

Though it may seem that Studio uses magic, everything is very clear here. Every time you click somewhere in Studio, you create a new record in the database. Understanding which records are created will really help you with making a list of pros and cons.

Each created field will be preceded by the prefix x_studio_. For example, x_studio_delivery_notes. In this way, you can understand that the field was created manually and not from any Python code.

Models will have an x_ prefix. E.g., x_equipment_log. The Studio will generate the model, default form view, and list view along with access rules and the menu. Views are not editable. The Studio will generate inherited views, which are XPath modifications and stored under the ir.ui.view. The modifications you do will be done on top of the default form view.

This record will be created in the table named ir.model.data. The module name will be "studio_customization", and the value for the field ‘studio’ will be True, which means Odoo will recognize this as something from Studio. All can be exported afterwards.

All of it will exist in the database without any repository, commit, or pull request. This is both its power and flaw.

Where changes are stored - Studio vs Module

Changes to the studio will be recorded in the database. Module codes will be stored in files with history.

When to use Studio

Use Studio when making changes that are not complex:

• Additional fields to an already designed form (reference, drop-down, date)
• Rearrangement of the design of a view, field hiding and renaming.
• Design of simple models for storing simple information (internal register, checklist).
• Simple automations. When the status becomes X, assign to Y. Send an email template.
• Reporting by PDF changes.
• Prototypes. This is something tangible that you have to demonstrate to the users.

If you can do it by a functional consultant in one afternoon with no development required and the customer is satisfied, use Studio. There is no need to pay developer rates to add a field.

When it gets tricky - you still need Python knowledge

There is a myth about Studio being 'no code'. However, that is far from the truth. As your automations become more complex, you'll use the Server Actions with 'Execute Python Code'. There will be some real Python used within a sandboxed environment. You won't have many variables and can't import things freely. Creating something that works in testing but fails at the edge cases is very simple.

Studio is not eliminating the requirement of technical skills; it's just concealing it. Python code inside the database within the server actions:

• Not linted or tested.
• No code review.
• No version history (unless otherwise specified).
• Hard to debug.

When you have 12 automations that use multi-line Python in your Studio configuration, you are coding anyway.

What Studio cannot do

There are some things that Studio doesn't allow you to do:

• No custom controllers. It is not possible to define any HTTP routes, public API endpoints, webhooks, or any custom web pages with server-side backend logic. This will require a Python module.
• No custom OWL components. In case you need a custom widget, a dashboard with some custom interactivity, or a custom kanban with some custom behaviour, you will require JavaScript and OWL. This will definitely require a real module.
• Unable to override core model methods properly. It is not possible to properly extend create(), write(), or computed methods with proper inheritance and super() calls. The only thing possible is to create automations.
• Complex constraints, computed fields, and optimizations. Computed fields, SQL constraints, indexed fields, and batch-optimized methods all want to be implemented in code.
• Anything with external integrations requiring proper error handling, retries, and authentication.

If your needs include any of the following, begin planning for a module:

Endpoint, Widget, Integration, Override.

Exporting - studio_customization vs Git Module

Your customizations in Studio can be exported as a module. This will usually be named studio_customization. This will generate a module that has all your XML code for fields, views, models, and actions. It will be quite useful to move your changes from your test database to the production database.

However, this is just a snapshot of your database. It is not a module per se. When compared to a true hand-coded module:

While it’s fine to use this as a transport method, it is not a good process for developing. If two people edit in Studio on different databases or a change is made on production ‘just this once', then you wouldn’t know what the right answer is. Using a git module will give you the answer.

Upgrade Testing

This is often forgotten. Each new version of Odoo introduces changes in views, changes field names, and generally modifies the structure. Your customization is based upon it.

Modifications in Studio work through inherited views. What it means is that the modifications are related to some element from standard views. When the base view changes in Odoo 20 and the element you are referencing in your XPath has changed its position or name, your customization won't be applied or will cause an error. As everything is stored in the database, there's no easy way to see what changes you've made. You will have to manually check what has happened.

Custom modules may also introduce problems, but you have several options to deal with them. You can inspect the code, do testing, search for deprecated methods, and do migrations. All errors will give you the file name and line number.

Top Tips

• Always do upgrades on a production copy.
• Write down your customizations. If it is a Studio, then you should go through all your views and automate processes. And for other modules, just check out your dependencies and overrides.
• Run your workflow and see that everything goes as it should. Make an entry, run your automation, and see your report.
• Be prepared for extra upgrade time if it is a Studio-heavy database. More customization requires more testing.
• The custom modules will require a refresh to be compatible with new Odoo 20 APIs.

Specific to Odoo 20

Odoo 20 was launched in September 2026. In the release notes, there are 9 changes in Studio. Not a single one of these changes permits you to create custom controllers, OWL components, or override methods. All these changes are basically improvements. It is also stated in the release notes that no data migration is needed for any of the Studio changes.

Studio Changes in Odoo 20

There are 2 more changes in Odoo 20 that will affect modules.

• Access Control has been updated. Access control is now done based on a new object (ir.access). It is imported from ir.access.csv and has an optional domain for each access rule. Security files in any custom module would need to be reviewed and updated.
• Values for tracking have been modified. The burndown chart and stage duration have been updated accordingly. For administrators requiring the old values, they could install a particular module. Modules relying on the tracking values would need testing.

Hybrid Approach (Recommended)

The most ideal systems will combine the two. Provided there are clearly defined ownerships.

Studio:

• Easy-to-use fields and layouts.
• Small-sized models.
• Prototypes.

Git Module:

• Whatever has any sort of business logic.
• Whatever is related to accounting, valuation of inventories, or compliance.
• Controllers, OWL modules, integration.
• Whatever you would be upset about losing.

Some simple rules:

• Take items out of the studio. If the Studio customisation is complicated enough, move it into a module. Use Studio for prototyping purposes.
• Avoid duplication. If you already have a custom view in a module, do not go on and make another in Studio. It should be owned by one individual.
• Document changes made. It is better to write down basic information (who, what, why, when) than try to remember it.
• Restrict access to Studio. Allow only 2-3 people.
• Export your work often. Git would suffice as a minimum requirement.
• Naming. Be sure you can differentiate your work from anyone else’s.

Quick Decision Maker

• "Just fields and layout?" Use Studio.
• "Simple automation with built-in actions?" Use Studio.
• "Requires more than a few lines of Python?" Use Module.
• "Requires a controller, route, or API?" Use Module.
• "Requires a custom OWL component or JS?" Use Module.
• "Multiple developers working on or requiring testing?" Use Module.
• "Critical?" Use Module.
• "Not sure?" Use Studio and then move to a module.

Studio is not the cheap solution, and custom modules are not the serious solution. They are two distinct tools, and they will each fail in their own way. The Studio will fail quietly, most likely during an upgrade process, since no one knows what has changed. Modules will fail loudly, most likely because they are overly complex.

Use Studio for easy wins and quick changes. Use modules for anything that needs structure. This will make your future self very happy while reviewing your upgrade checklist.

To read more about How Much Does Odoo Studio Cost in Odoo 20?, refer to our blog How Much Does Odoo Studio Cost in Odoo 20?.