Two ways to change the same system
You need a field Odoo does not have. Or a screen rearranged. Or a rule about who approves what.
There are two tools for this, and they are often presented as competitors. They are not. They handle different sizes of problem, and using the wrong one is where the cost appears.
Odoo Studio is a drag-and-drop customiser built into Enterprise. No code.
Custom development is a developer writing a module. Code, in a separate package.
Knowing which to reach for saves both money and future pain.
What Studio does
Studio lets someone without programming skills change Odoo from inside the interface.
It can:
- Add fields to a form
- Move fields around and change their labels
- Add tabs and sections
- Create simple automated rules
- Modify report layouts
- Build small new apps for straightforward record-keeping
The person doing this clicks and drags. There is no code and no deployment step. The change appears immediately.
FIGURE 1: WHAT STUDIO IS GENUINELY GOOD AT
Adding a field
- A customer’s preferred delivery day, an internal reference, a checkbox somebody needs.
Rearranging a screen
- Moving the fields your team uses most to the top of the form.
Simple rules
- Send a notification when a field changes, or set a value automatically.
Where Studio stops
Studio has real limits, and hitting them halfway through a project is expensive.
Complex logic. If your rule involves several conditions, a calculation across records, or anything that depends on data from another model, Studio will not express it.
Anything performance-sensitive. Studio’s automations are fine at low volume. They are not the right tool for something that runs on thousands of records.
Integrations. Talking to another system needs code.
Version control. This is the limit people underestimate. Studio changes are made by clicking. There is no history of who changed what, or why, and no way to review a change before it goes live. In six months, nobody will remember why that field exists.
Testing. A Studio change applies immediately to your live system. There is no test-then-release step unless you deliberately work in a separate database and re-do the changes.
What custom development does
A developer writes a module — a separate package of code that adds fields, logic, views and reports.
It can do everything Studio does, plus everything Studio cannot: complex calculations, multi-step approval routes, integrations with other systems, redesigned business processes.
Three things come with it that Studio does not have.
Version control. The code lives in a repository. Every change has an author, a date and a reason. You can see the history and roll back.
A test cycle. Changes are built and tested somewhere safe, then released. Your live system is not the place where new work first runs.
Reviewability. Another developer can read the code and understand what it does. That matters when the person who wrote it moves on.
FIGURE 2: WHAT YOU GET AND WHAT YOU GIVE UP
Custom module
- Any complexity of logic
- Full change history and rollback
- Tested before it reaches live
- Any developer can review it
Studio
- Simple changes only
- No record of who changed what
- Applies straight to your live system
- Hard to audit after the fact
The honest comparison
Studio is faster and cheaper for small things. That is real and it matters.
Custom development is slower and more expensive up front, and it produces something you can maintain, test and hand to a different developer in three years.
The mistake is not choosing one over the other. It is using Studio for something that has outgrown it — and then discovering, at the next upgrade or the next audit, that nobody can explain what the system is doing.
A working rule
Ask two questions about any change.
Is it structural or cosmetic?
Adding a field to record information, moving fields around, adjusting a report layout — cosmetic. Studio handles these well.
Changing how a price is calculated, when an order can be confirmed, what triggers an approval — structural. These belong in a module.
Would you want a record of why this was done?
If yes, it needs code. Business rules always need this. A field label rarely does.
FIGURE 3: A PRACTICAL DECISION PATH
Check configuration first
- Price lists, payment terms, approval thresholds. Free, and more is possible here than people expect.
Cosmetic change? Use Studio
- Adding a field, moving things, tweaking a report layout.
Structural change? Build a module
- Calculations, approval routes, anything integrating with another system.
Never edit core files
- Whatever the pressure. This is the rule that protects your upgrades.
Where Studio quietly becomes a problem
A pattern worth recognising.
A company starts with one or two Studio fields. Reasonable. Over two years, dozens accumulate. Some feed calculations. Some are referenced by automations. Nobody documented any of it.
Then something breaks, or an upgrade is due, and the work of untangling it costs more than building it properly would have.
Two safeguards, if you use Studio:
Keep a simple written log of every Studio change — what, when, why, who asked for it. A shared document is enough.
Review it every six months. Remove what is no longer used, and move anything that has grown into real logic over to a proper module.
What to ask a partner
If a partner proposes Studio for a substantial piece of work, ask:
- How will we know what was changed, six months from now?
- What happens to this at the next version upgrade?
- Where will it be tested before it reaches our live system?
- If we later need to extend it, does it have to be rebuilt?
Reasonable answers exist for small changes. If the answers are vague and the change is significant, that is your signal.
The balance
Use configuration first, because it is free and there is nothing to maintain.
Use Studio for small cosmetic changes, and write down what you did.
Use a module for anything that is really a business rule.
The best installations use all three deliberately — not one tool for everything because it happened to be available.
Not sure whether your change needs Studio or a module?
Get in touch. We will look at the specific requirement and tell you honestly which one fits, including the cases where the answer is that a setting already does it.
