You need a field Odoo does not have. Or a screen rearranged. Or a rule about who approves what.<\/p>\n
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.<\/p>\n
Odoo Studio<\/strong> is a drag-and-drop customiser built into Enterprise. No code.<\/p>\n Custom development<\/strong> is a developer writing a module. Code, in a separate package.<\/p>\n Knowing which to reach for saves both money and future pain.<\/p>\n Studio lets someone without programming skills change Odoo from inside the interface.<\/p>\n It can:<\/p>\n The person doing this clicks and drags. There is no code and no deployment step. The change appears immediately.<\/p>\n FIGURE 1: WHAT STUDIO IS GENUINELY GOOD AT<\/p>\n Adding a field<\/p>\n Rearranging a screen<\/p>\n Simple rules<\/p>\n Studio has real limits, and hitting them halfway through a project is expensive.<\/p>\n Complex logic.<\/strong> If your rule involves several conditions, a calculation across records, or anything that depends on data from another model, Studio will not express it.<\/p>\n Anything performance-sensitive.<\/strong> Studio’s automations are fine at low volume. They are not the right tool for something that runs on thousands of records.<\/p>\n Integrations.<\/strong> Talking to another system needs code.<\/p>\n Version control.<\/strong> 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.<\/p>\n Testing.<\/strong> 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.<\/p>\n A developer writes a module \u2014 a separate package of code that adds fields, logic, views and reports.<\/p>\n It can do everything Studio does, plus everything Studio cannot: complex calculations, multi-step approval routes, integrations with other systems, redesigned business processes.<\/p>\n Three things come with it that Studio does not have.<\/p>\n Version control.<\/strong> The code lives in a repository. Every change has an author, a date and a reason. You can see the history and roll back.<\/p>\n A test cycle.<\/strong> Changes are built and tested somewhere safe, then released. Your live system is not the place where new work first runs.<\/p>\n Reviewability.<\/strong> Another developer can read the code and understand what it does. That matters when the person who wrote it moves on.<\/p>\n FIGURE 2: WHAT YOU GET AND WHAT YOU GIVE UP<\/p>\n Custom module<\/p>\n Studio<\/p>\n Studio is faster and cheaper for small things. That is real and it matters.<\/p>\n 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.<\/p>\n The mistake is not choosing one over the other. It is using Studio for something that has outgrown it \u2014 and then discovering, at the next upgrade or the next audit, that nobody can explain what the system is doing.<\/p>\n Ask two questions about any change.<\/p>\n Is it structural or cosmetic?<\/strong><\/p>\n Adding a field to record information, moving fields around, adjusting a report layout \u2014 cosmetic. Studio handles these well.<\/p>\n Changing how a price is calculated, when an order can be confirmed, what triggers an approval \u2014 structural. These belong in a module.<\/p>\n Would you want a record of why this was done?<\/strong><\/p>\n If yes, it needs code. Business rules always need this. A field label rarely does.<\/p>\n FIGURE 3: A PRACTICAL DECISION PATH<\/p>\n Check configuration first<\/p>\n Cosmetic change? Use Studio<\/p>\n Structural change? Build a module<\/p>\n Never edit core files<\/p>\n A pattern worth recognising.<\/p>\n 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.<\/p>\n Then something breaks, or an upgrade is due, and the work of untangling it costs more than building it properly would have.<\/p>\n Two safeguards, if you use Studio:<\/strong><\/p>\n Keep a simple written log of every Studio change \u2014 what, when, why, who asked for it. A shared document is enough.<\/p>\n 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.<\/p>\n If a partner proposes Studio for a substantial piece of work, ask:<\/p>\n Reasonable answers exist for small changes. If the answers are vague and the change is significant, that is your signal.<\/p>\n Use configuration first, because it is free and there is nothing to maintain.<\/p>\n Use Studio for small cosmetic changes, and write down what you did.<\/p>\n Use a module for anything that is really a business rule.<\/p>\n The best installations use all three deliberately \u2014 not one tool for everything because it happened to be available.<\/p>\n Not sure whether your change needs Studio or a module?<\/p>\n 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.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":" 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 […]<\/p>\n","protected":false},"author":3,"featured_media":9074,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[25],"tags":[],"class_list":["post-9073","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-odoo"],"yoast_head":"\nWhat Studio does<\/h2>\n
\n
\n
\n
\n
Where Studio stops<\/h2>\n
What custom development does<\/h2>\n
\n
\n
The honest comparison<\/h2>\n
A working rule<\/h2>\n
\n
\n
\n
\n
Where Studio quietly becomes a problem<\/h2>\n
What to ask a partner<\/h2>\n
\n
The balance<\/h2>\n