Odoo Studio vs Custom Modules vs Odoo.sh: Which Route Fits

If you are weighing Odoo Studio, custom modules and Odoo.sh, the first thing to know is that they are not three competing options. They answer two different questions.

• How do I change Odoo? Either with Studio (no-code configuration) or with a custom module (code).
• Where does Odoo run? Odoo Online, Odoo.sh or on-premise.

Odoo.sh is a hosting platform, not a customization method. It matters in this decision because your hosting choice decides whether custom code is even allowed.

The short answer

• Add fields, adjust views, tweak reports, build simple approvals or a small internal app: start with Studio.
• Need real business logic, integrations, complex validation or behavior Studio cannot express: write a custom module.
• Run custom modules and want branches, staging and automated backups without managing servers: Odoo.sh is the usual home. Self-hosting is the alternative.
• Want the least maintenance and can live without custom code: Odoo Online with Studio.

Most healthy Odoo projects use all of it: Studio for the small stuff, a handful of well-built modules for the differentiating stuff, and a hosting choice that fits.

What Studio is good at

Odoo describes Studio as a toolbox for customizing Odoo without coding knowledge. Per the documentation, it covers fields and views, new models and apps, automation rules and webhooks, PDF reports, approval rules and security rules.

That is a lot of day-to-day work. Typical good fits:

• A custom field on a sales order or contact.
• A rearranged form or list view.
• A branded quotation or delivery slip layout.
• A manager-approval step on purchase orders above a threshold.
• A simple tracking app, such as an equipment register or an internal request form.

Studio changes are fast to make, can be done by a capable functional consultant or power user, and are stored inside the database in a form Odoo understands. That generally makes them easier to carry through upgrades than hand-written code, though you should still test them. Odoo’s documentation does not make guarantees here, so treat that as experience, not a promise.

Where Studio runs out

Studio is configuration. A third-party write-up from Cybrosys notes that heavy customization can confuse users, that changes to manufacturing modules are hard to do well, and that uninstalling Studio removes the apps and customizations built with it. Beyond those points, our own experience is that Studio runs out when the need is advanced business logic, complex validation or specialized interface behavior. In practice, that means:

• Calculations that depend on many records or external data.
• Multi-step workflows with branching rules that go beyond approvals.
• Integrations with a warehouse system, marketplace, payment provider or tax engine.
• Performance-sensitive logic, such as bulk processing.
• Anything where you need unit tests and code review.

There is also a commercial point. Odoo’s pricing page lists Studio under the Custom plan, not Standard, and the Studio documentation notes that installing it on a Standard-plan database triggers an upgrade to Custom. Check current per-user prices for your region on that page, because they vary by currency and billing terms. If you only need two or three extra fields, the plan difference may not be worth it for the whole team.

What custom modules are good at

A custom module is Python, XML and (sometimes) JavaScript that you or a partner write and deploy alongside standard Odoo. It is the right tool when the requirement is genuinely about behavior:

• Business rules that differ from standard Odoo flows.
• Integrations through APIs, EDI or middleware.
• New data models with real constraints.
• Reports that need heavy queries.
• Automated tests, version control and a proper release process.

The cost is ownership. Custom code has to be maintained, and upgrades are where this shows up. Odoo’s upgrade documentation is blunt: a database with custom modules cannot be upgraded until a version of those modules exists for the target Odoo version, and their source code must be up to date with the target version first. Odoo recommends doing both in parallel, with an upgraded test database while you update the module code.

Odoo’s pricing page also says that maintenance of custom code is not included in the subscription. Budget for it as a recurring line, not a one-off build cost.

A sensible rule: write code only when Studio or standard configuration cannot do the job, and keep each module small and focused. Before building from scratch, check whether an existing open-source module from the Odoo Community Association already covers the need, and read its code and maintenance record before depending on it.

Where Odoo.sh fits

Odoo.sh is Odoo’s official cloud platform for hosting Odoo applications, with continuous integration, a web shell, SSH access and support for your own modules. According to the branches documentation:

• Projects have development, staging and production stages. Staging exists to test new features with production data without touching production.
• Pushing a commit to the production branch updates and restarts the server. If the update or restart fails, the server reverts to the last successful revision and rolls the database back.
• Production is backed up automatically, with seven daily, four weekly and three monthly copies, covering the database, filestore, logs and sessions.

For teams with custom modules, that workflow is the main benefit: you can test a change against a copy of real data before it reaches users. Odoo’s pricing page states that Odoo.sh is available on the Custom plan and that the hosting cost is not included in the plan price.

The hosting trade-off

Option	Custom code	Best for	Watch out for
Odoo Online	No	Standard Odoo plus Studio, minimal IT effort	Odoo’s documentation says it is incompatible with custom modules and Apps Store modules
Odoo.sh	Yes	Teams with custom modules who want managed staging and backups	Separate hosting cost; you still own your code
On-premise / self-hosted	Yes	Strict data-residency, network or security requirements	You run servers, backups, monitoring and security patches

This is the point many buyers miss. If you start on Odoo Online with Studio and later discover you need a custom module, you will have to change hosting. Better to decide on day one whether custom code is likely.

A practical decision path

1. List the changes. For each, write one sentence on the behavior you need.
2. Check standard Odoo first. Many “custom” requests are a setting or an existing app.
3. Sort the rest. Fields, views, reports and simple approvals go to Studio. Logic, integrations and anything needing tests go to a module.
4. Pick hosting from that list. If any item needs code, rule out Odoo Online.
5. Plan for upgrades. Keep a list of every Studio customization and every module, with an owner. Test them on a copy of your database before each major version.

Common mistakes

• Stretching Studio into a code substitute. Piles of automation rules that mimic code are hard to debug and hard to review.
• Writing a module for a one-field change. You have just bought yourself an upgrade task.
• Treating Odoo.sh as a customization option. It hosts your work; it does not replace the decision about how to build it.
• Skipping staging. A copy of production data is the cheapest insurance you have.

Our view

Use the lightest tool that does the job. Studio first, modules where behavior demands them, and a hosting platform chosen to match. Keep the customization footprint small, because every extra module or rule is something you will carry through every upgrade.

If you are unsure which route fits a specific change, or you inherited a database with a mix of both, we are happy to talk it through. Teknologia Solutions offers a no-charge conversation: no pitch, just a candid read on your options.

---

Sources: Odoo Studio documentation; Odoo pricing; Odoo upgrade documentation; Odoo.sh documentation; Odoo.sh branches; Odoo Online documentation; Cybrosys on Studio limitations; Odoo Community Association. Plans, pricing and platform behavior change between Odoo versions; verify against Odoo’s primary documentation and your own contract before deciding.