There are three ways to change how Odoo behaves, and they are not interchangeable: configuration, Odoo Studio, and a custom module. Configuration adjusts settings and rules Odoo already ships with. Studio is Odoo’s own no-code builder, available on the Custom plan. A custom module is Python and XML, written by a developer, tested and installed like any other piece of software. The right choice is usually the lightest one that still survives the next upgrade, not the one that feels most impressive in a demo.
This is not a question of whether to change something in Odoo. That decision belongs to a separate conversation. Assume it has already happened: something in the system genuinely needs to change. What follows is how to choose the method that builds it, and the trade-offs each method makes on your behalf whether anyone notices them or not.
What configuration alone can do
A surprising share of requests that sound like customization are actually configuration, worth ruling out first since it costs nothing beyond finding the right screen. It uses settings and rules already built into Odoo, turned on or adjusted for how a business runs, with no developer or Studio session required.
- User access and roles. Who can see, edit, approve, or delete records is a matter of groups and access rights, set from Users and Companies.
- Price lists. Customer-specific pricing, quantity breaks, and time-limited discounts are built into the Sales app’s pricelist rules.
- Approval rules. Purchase order double validation above a threshold is a settings toggle, not development work.
- Automated actions. Odoo’s own automation rules trigger an action when a record is created, updated, or reaches a chosen state, with no Python needed for common cases.
- Email templates. The wording, timing, and recipients of automatic emails are editable directly, without touching a line of code.
- Reporting filters. Saved filters and favorites on list, pivot, and graph views cover most “I need a report that shows” requests without a custom report ever being built.
- Warehouse routes. Multi-step delivery, cross-docking, and dropshipping are route configurations in the Inventory app, not custom logic.
None of this needs Studio or a developer, and none of it creates anything a future upgrade has to check, since nothing new was written. More requests that arrive sounding like a “custom feature” resolve at this level than most teams expect.
What Odoo Studio is genuinely good at
Studio is a real tool with a genuinely useful range, included on Odoo’s Custom plan. It lets a trained admin make a meaningful set of changes without writing code or waiting on a developer’s calendar.
- Adding fields. New fields on any model, placed exactly where they need to sit on the form.
- Tweaking form and list views. Rearranging, hiding, and adding tabs or buttons, by dragging elements rather than editing XML.
- Simple automations. A friendly interface over Odoo’s automation rules: when this happens, do that, with a condition in between.
- Custom reports. A drag-and-drop report designer for PDF and print layouts, without touching the underlying template language.
- Small approval steps. Adding an approval stage to a workflow that did not already have one.
Its real limits show up just as clearly, once a request goes past that range.
- Complex logic. More than one condition feeding into another strains an interface built for simpler rules.
- Performance-sensitive work. Bulk operations and heavy queries running on a schedule need code written with performance in mind.
- Anything needing tests or version control. Studio changes carry no automated test and no meaningful diff to review before they go live.
- Deep integrations. A webhook or a REST call to an external system is development work, not a Studio automation.
Studio can technically attach a short piece of Python code to an automation rule’s action, which is where no-code and code with none of the usual safeguards start to blur. Treat that option as a sign the request has outgrown Studio, not a shortcut around building a proper module.
When a custom module is the right answer
A custom module is the correct tool, not the expensive fallback, when a request has real substance behind it.
- Real business logic. Multi-step calculations or conditional pricing that depends on several factors at once belongs in code that is structured and named properly, not a form full of Studio conditions.
- Integrations. Connecting Odoo to a system with no ready-made connector, or syncing records both ways against another platform’s API, is development work by definition.
- Performance work. Optimizing a slow report or a heavy scheduled job against a large volume of records needs code written and measured for that purpose.
- Anything that needs tests and version control. A mistake here that would be expensive or embarrassing deserves an automated test that catches it before a user does, and a commit history that shows who changed it and why.
- Work another developer will need to maintain. Code in a repository is something a new developer can read. A Studio automation is something they have to reconstruct by clicking through it.
This is the kind of build our Odoo customization work covers: built as an official Odoo Partner and quoted as a fixed fee rather than billed by the hour.
Configuration, Studio, or a custom module: a straight comparison
Put side by side, the trade-offs are consistent enough to use as a working reference.
| Method | Who can do it | Upgrade risk | Testability | Version control | Typical use | Hidden cost |
|---|---|---|---|---|---|---|
| Configuration | Admin or power user | Minimal, nothing was written to break | Not usually needed, already tested by Odoo | None, lives in settings, not files | Access rights, pricing, approvals, routes, filters | Low, mainly a forgotten setting |
| Odoo Studio | Trained admin, rarely a developer | Moderate, depends how far past a simple field or view it goes | Manual click-through only, no test suite | None by default, stored in the database | New fields, view tweaks, simple automations, small reports | Grows quietly, easy to add and easy to forget |
| Custom module | A developer | Depends on code quality, reviewable at each upgrade | Full, automated tests are standard practice | Yes, native to how it is shipped | Business logic, integrations, performance-critical work | Development and review time, bounded and visible |
The maintenance truth nobody mentions at the demo
Every Studio demo looks the same. A field appears, or a view rearranges itself, in seconds, and the change feels like it cost nothing. In one sense it did not, since no code was written. What the demo does not show is where that change actually lives afterward.
A Studio change is stored directly in the database, the same way a customer or an invoice is a record. It has no diff and no pull request behind it, and rarely a comment explaining why it was added. Studio does include an export option that packages customizations into an installable module, but it is a snapshot, not a code review, and adds no tests to something that never had any.
A custom module lives in files, in a repository, with a change history showing who made a change and when. A second developer can review it before it ships, and automated tests catch a problem before a user does.
Neither approach is wrong on its own. The mismatch happens when a business treats Studio’s ease of use as evidence that the change itself was small, when what was actually small was the effort of making it, not what it left behind. If nobody in the business can take on that ongoing ownership, an outside support arrangement that includes reviewing what has changed is the more honest alternative to leaving it undocumented.
A practical rule of thumb
One test cuts through most of these decisions faster than a policy document. If the logic needs an if-statement more than one level deep, or if anyone will ever need to know why this exists a year from now, put it in a module. If the answer to both is no, Studio or configuration is very likely enough.
Apply it to a real example. A discount that depends on which customer is buying is one condition, comfortably inside Studio or a pricelist rule. A discount that depends on the customer, the order volume, the season, and whether a prior invoice was paid on time is four conditions feeding one decision, difficult to build correctly in a point-and-click tool and harder to debug six months later when one of those conditions changes. That is a module, built once and readable by whoever inherits it.
The mistake pattern worth naming
The most common failure is not choosing the wrong method once. It is using Studio as a quiet way to avoid a decision nobody wanted to make out loud. A request arrives that deserves a real conversation about whether it reflects an actual business need. Instead, someone adds a field, because adding a field is fast and needs nobody’s approval.
Repeat that forty times over a year, across a few different people, and the database now carries forty fields nobody can fully explain. Nobody wants to remove them, since nobody is certain what still depends on them, and every one gets carried through the next upgrade anyway, quietly adding to what has to be checked and explained to the next new hire.
Studio did not cause that outcome. Using it as a substitute for a decision did.
The method that wins should be judged by who has to maintain the result two years from now, not by which one is fastest to demo this week. A fast Studio change made by someone who leaves next quarter can end up costing more than a module that took a week longer to build and is still understood by whoever runs the system when the next Odoo version ships.
Frequently asked questions
What is Odoo Studio?
Odoo Studio is Odoo’s own no-code builder. It lets an admin add fields, adjust form and list views, build simple automations, and design reports, without writing Python or XML by hand.
Is Odoo Studio included in my plan?
Studio comes with Odoo’s Custom plan, priced from $61.00 per user per month in the US, billed yearly. The Standard plan, from $31.10, does not include it. Check this before committing to a plan; our Odoo pricing breakdown covers what each includes.
Can I customize Odoo without a developer?
For a real range of changes, yes. Configuration and Odoo Studio cover new fields, adjusted views, simple automations, and report changes without a developer. Business logic, integrations, and performance work still need one, and at that point the practical step is to hire an Odoo developer rather than push Studio further than it was built to go.
Is Odoo Studio or custom development better?
Neither is universally better. Studio is right when a non-developer can safely own the outcome, such as a new field or a small view change. Custom development is right when the logic is complex, performance matters, or the change needs testing and review before it reaches daily users.
Do Studio changes survive an Odoo upgrade?
Simple ones usually carry through cleanly. More complex Studio changes, especially ones layered over time, need the same review a custom module would get, even though they were built without code. Our Odoo upgrade page covers what an upgrade actually involves.
Do I need a developer to maintain Odoo customizations?
Configuration and straightforward Studio work can usually be maintained by a trained admin. A custom module, or a Studio automation complex enough to carry its own logic, needs someone with development skill to maintain it safely. We staff that work with in-house developers rather than subcontractors, for the accountability reason this whole comparison keeps coming back to.
If you are not sure which side of this line a specific request falls on, bring it to a free demo and we will tell you honestly.