Sooner or later someone in your company opens Odoo Studio, drags a new field onto a form, and solves in a few minutes what would otherwise have sat on a developer's list for weeks. That is Studio doing its job. The trouble shows up later, when the same database carries dozens of small changes, nobody remembers who made them or why, and a version upgrade is on the calendar. So when you choose between Studio and custom code, the useful question is what each change will cost you after the day it is made.
What Studio does well
Studio is an Odoo Enterprise app, so confirm your plan includes it before you count on it. It lets a trained administrator change Odoo from the screen itself, without writing code:
- Fields. Add a field to a model and place it on a form, list, or search view.
- Layouts. Move, hide, relabel, or require fields, and add tabs or columns.
- PDF documents. Adjust the layout of quotations, invoices, and similar reports.
- Automation rules. Set a value, send a message, or create an activity when a record changes or a date arrives.
- Small apps. Track something Odoo does not cover, such as equipment loans or vehicle permits.
For changes like these, Studio is usually the right answer. Paying a developer to add a reference field to a sales order is rarely money well spent, and the person who asked for the field can check the result immediately.
What you give up
The limits that matter most have little to do with features. Studio changes live in the database, and that has consequences:
- No review. There is no pull request and no second pair of eyes. Two administrators can make conflicting changes without either one knowing.
- Live immediately. Unless you work on a copy and move the changes across, an edit reaches every user as soon as you make it.
- No automated tests. Nothing confirms that a rule still behaves correctly after the next upgrade.
- Edits that can come loose. A Studio view edit is a layer on top of the view it changes. If the underlying view changes during an upgrade, that layer may stop applying and need rework.
- A harder exit. Uninstalling the module that holds your Studio work can remove the fields it created, along with the data in them. Replacing Studio with code later means carrying that data across first, and rehearsing the move on a copy.
When custom code is the better choice
Custom development earns its cost when the change holds logic your business depends on. The usual signs you have moved past Studio:
- The rule has branches. A commission that depends on product category, margin, and who closed the deal is a small program. Written as Python snippets inside automation rules, it is still a program, just one nobody reviews.
- Standard behavior has to change. Studio adds to Odoo's screens and triggers. Changing what happens when a delivery is validated or an invoice is posted calls for development.
- Another system is involved. An automation rule can send a webhook, but retries, error handling, and reconciling failures are development work.
- Volume matters. Logic that runs across many thousands of records has to be written and tested with performance in mind.
- A mistake would be expensive. Anything touching journal entries, tax, payroll, or stock valuation deserves review, tests, and a trial run before release.
Custom code has its own bill. It needs a developer and a test cycle, and someone has to keep it working at every upgrade, including the modules nobody uses anymore.
Three questions that settle most cases
- If this breaks, who notices, and how fast? A misplaced field is annoying and obvious. A wrong number in a journal entry can sit unnoticed until the auditors arrive.
- Can you describe the change without the word "if"? "Add a delivery zone field to the sales order" fits Studio. "If the zone is remote and the order is below a set value, add a surcharge unless the customer is on contract" does not.
- Will anything else depend on it? A field that reports, integrations, or custom modules read is part of your data model, so give it a deliberate name and an owner. A module that reads a Studio field breaks if someone later deletes it, and that person may have no idea the module relies on it.
Keeping Studio under control
A few habits stop Studio from delaying your next upgrade:
- Name one or two owners instead of opening it to everyone with admin rights.
- Try changes on a staging copy first when the screen is used all day.
- Keep a short log of what changed, who asked, and why. The database records the change but not the reason.
- Review the full list before each version upgrade, and remove what nobody uses.
Where Plemo fits
Studio is quick and unreviewed. Traditional development is reviewed and slower. Plemo is aimed at the changes in between, where the person who understands the business can describe the need but the result should not go straight to production. You describe the change in a chat, and the AI asks clarifying questions and narrows requests that are too broad to build well in one pass. You approve a written spec before development starts, then check the result in a sandbox before anything reaches production. AI usage is credit based, so a tightly scoped request also costs less.
That is still a development cycle, and it is more process than a relabeled field deserves. If Studio can do it in a minute and nothing depends on it, use Studio. At the other end, a change that reshapes a core process across several departments needs someone to question the process before anything gets built. Our custom development team can help with that call, and with sorting an existing pile of Studio changes into what to keep, rebuild, or remove.