Choosing between Odoo custom module vs Studio and plain configuration is one of the most consequential decisions in any implementation. A competent customization team does not default to the heaviest option. It defaults to the lightest one that solves the problem. This guide explains how that decision should work and what it means for upgrade cost and long term flexibility.
📋 Key Takeaways
- Four ways exist to change Odoo. Configuration, Studio, a custom module, and external integration, each adding capability and upgrade cost.
- The default should be the lightest option. Configuration first, Studio if that falls short, and custom code only for genuine gaps.
- Configuration costs nothing to maintain across upgrades and Studio costs little, while custom modules cost 20 to 40 percent of the original build per major version.
- A company that quotes a custom module for every requirement either lacks functional knowledge or is selling development hours.
- Document the decision so the rationale survives after the people who made it move on.
📑 Table of Contents
- The Four Levels of Changing Odoo Behaviour
- When Configuration Alone Solves It
- When Studio Is Enough
- When a Custom Module Is Justified
- When Integration Beats Code Inside Odoo
- Upgrade Cost of Each Path
- Maintenance Burden Over Time
- How a Good Company Defaults to Lightest
- Documenting the Decision
- Spotting a Company That Over Customizes
- FAQs
Odoo Custom Module vs Studio: The Four Levels of Changing Behaviour
- Level 1, configuration. Standard Odoo settings, workflow rules, automated actions, and approval rules with no code. It uses what Odoo provides out of the box at zero upgrade risk, where configuration and customization first diverge.
- Level 2, Studio. A visual editor that adds fields, modifies views, and builds basic automations without Python. Available in Odoo Enterprise only, with low upgrade risk.
- Level 3, custom module. Python code that extends Odoo models, views, or business logic for requirements beyond configuration and Studio, with medium to high upgrade risk.
- Level 4, external integration. Connecting Odoo to an external system through an API when the capability does not belong inside Odoo, such as payment or shipping. Maintenance is ongoing.
Every level up adds capability and cost. The right choice is the lowest level that fully solves the problem, since going higher wastes money on the build and on every upgrade.
When Configuration Alone Solves It
Configuration handles far more than most teams expect, which is why a sound implementation starts here, before any code.
Configuration handles more than most people expect
- Approval workflows. Multi level purchase or sales approval on amount thresholds, built in.
- Automated actions. Assign a delivery team by customer region when an order is confirmed.
- Scheduled actions. Run a nightly stock check and alert when a product falls below minimum.
- Access control. Sales staff see only their own quotations and the warehouse team cannot open accounting.
- Basic custom fields. Adding a text, selection, or date field through developer mode without Studio or code.
- Report formatting. Modifying invoice layout, adding a logo, or changing column order through a QWeb template.
A functional consultant who knows Odoo deeply solves 50 to 70 percent of requirements at this level. Teams that skip Odoo consulting and go straight to a developer miss them.
When Odoo Studio Is Enough
Studio handles the gap between configuration and code
- Computed fields. A field that calculates margin from sale price and cost using formula fields.
- View changes. Moving fields between tabs, adding a tab, or showing fields based on a condition.
- Custom reports. A report that combines sales and inventory data in the format your management needs.
- Simple automations. When a lead reaches a stage, create a project task. When an invoice is 30 days overdue, notify the account manager.
⚠️ Studio limitations
- Cannot change core business logic such as tax calculation, inventory valuation, or how production consumes materials
- Cannot create new models with complex relationships
- Cannot build API integrations with external systems
- Available only in Odoo Enterprise, so Community users cannot use it
- Complex Studio changes become hard to maintain as they accumulate, and many on one form create fragility
When a Custom Module Is Justified
Custom code is the right answer when the work goes beyond standard tools
- New business logic. A pricing calculation Odoo cannot handle natively, such as weight based slab rates with customer specific discounts together.
- New data model. A new entity Odoo has no equivalent for, such as a compliance register or an industry specific workflow.
- Core behaviour change. Changing how Odoo processes a transaction, such as landed cost allocation or the sequence of operations in manufacturing.
- Complex validation. Cross field validation across several models, such as a credit check on outstanding balance and payment history before a new sales order.
Every custom module is a maintenance commitment. It must be tested at every update, documented, and budgeted for upgrade. The true customization cost is the build plus two to three upgrades over five years.
When Integration Beats Code Inside Odoo
Some capability does not belong inside Odoo, and a clear view of how Odoo apps connect shows when a third party integration is cleaner.
- Payment processing. Connect to Razorpay or PayU through an API rather than building payment logic.
- Shipping and logistics. Connect to Shiprocket, Delhivery, or a 3PL through their API rather than replicating shipping rates.
- Specialised calculation. Tax engines, credit scoring APIs, or regulatory tools. Use the service and bring the result into Odoo.
- Business intelligence. Connect Odoo to Metabase, Power BI, or a data warehouse rather than building reporting engines inside it.
Upgrade Cost of Each Customization Path
Cost is not only the build. The real question is what each path adds to every future upgrade cost, weighed against the figures in our Odoo pricing guide.
- Configuration. Zero upgrade cost. Standard settings migrate automatically between Odoo versions.
- Studio. Minimal. Studio changes are stored as data and most survive upgrades. Budget ₹5,000 to ₹15,000 per major version for validation.
- Custom module that is well written. Around 20 to 40 percent of original development cost per major version.
- Custom module that is poorly written. Often 50 to 100 percent of original cost, a rewrite at every version.
- External integration. Ongoing. API changes, authentication updates, and endpoint deprecation need maintenance regardless of Odoo version.
Maintenance Burden Over Time
- Configuration. Zero maintenance. It is part of Odoo, and ongoing hosting and administration already covers it.
- Studio. Low. Occasional adjustments when Odoo changes a view structure, manageable by any competent Odoo team.
- Custom module. Medium to high. It needs a developer who knows the codebase, and poor documentation makes the code slower to understand than to write.
- Integration. Ongoing. External APIs change on their own schedule, so monitoring, error handling, and adaptation are continuous tasks.
Every custom module you build is a dependency you maintain forever. Ten custom modules mean ten dependencies to validate at every update, while solving seven with configuration leaves only three.
How a Good Company Defaults to the Lightest Option
The decision process of a competent company
- Step 1, can configuration handle it. Check standard settings, workflow rules, automated actions, and access control.
- Step 2, can Studio handle it. Check whether a computed field, view change, or simple automation solves it.
- Step 3, is it a custom module or an integration. Decide whether the logic belongs inside Odoo or outside it, then choose accordingly.
- Step 4, document why. Record which options were considered and why each was rejected, saving money at the next upgrade.
A short ERP audit before configuration pays for itself by confirming what standard Odoo already does before anyone quotes development.
Documenting the Customization Decision
What the decision document should contain for each requirement
- Business requirement. What the user needs in plain language.
- Options considered. Configuration, Studio, custom module, and integration, with why each was selected or rejected.
- Selected option. Which level was chosen and why.
- Upgrade impact. What happens to this customization when Odoo upgrades, plus estimated effort.
- Owner. Who maintains it, whether an internal team or a vendor.
This document is the most valuable artifact a customization company produces. Not the code, but the rationale that stops the next team from repeating the evaluation.
How to Spot an Odoo Company That Over Customizes
Before you sign with any Odoo customization company, read the proposal the way a seasoned Odoo ERP consultant would.
Warning signs to watch for
- Every requirement becomes a custom module quote with no configuration or Studio alternative
- The company asks how to build something but never asks why you need it
- No gap and fit analysis before quoting development
- An implementation proposal that lists eight or more custom modules for a mid market business, when most need only two to four
- No mention of upgrade cost, so the build is sold but not the maintenance
- The team has only developers and no functional consultant, which matters because an on demand Odoo developer tends to solve every problem with code
Right Approach
Want a Customization Company That Defaults to the Lightest Option?
Tatvamasi Labs evaluates every requirement across all four levels before recommending custom code. Configuration first. Custom only for genuine gaps. Upgrade impact discussed upfront.
Discuss Your Requirements →Frequently Asked Questions
Configuration uses standard settings and automated actions with no code. Studio adds fields, views, and simple automations through a visual editor, with no Python but Enterprise only. Custom modules are Python code for needs beyond configuration and Studio. Each level adds capability and upgrade risk.
Use Studio for fields, view changes, simple reports, and basic automations. Choose a custom module for new business logic, complex calculations, API integrations, or changes to how Odoo processes transactions. Studio cannot change core behaviour.
Studio customisations are stored as data rather than code, so they survive upgrades better than custom modules. They can still break if they reference a view or field that changes in the new version. More upgrade safe than custom code but not immune.
If every requirement results in a custom module quote, the partner may lack functional knowledge of what standard Odoo already handles. For each item, ask whether Odoo or Studio cannot handle it. A competent partner explains why the lightest option does not work first.
Configuration has zero upgrade cost and Studio is minimal. A well written custom module costs around 20 to 40 percent of original development per major version, and a poorly written one costs far more. The heavier the customisation, the costlier every upgrade.
Yes. A common pattern is to prototype quickly in Studio, then rebuild the logic as a clean custom module once the requirement is stable. This keeps early iterations cheap and the final code maintainable.
Most mid market Odoo deployments need only two to four genuine custom modules. A proposal listing eight or more custom modules for a standard business is usually a sign of weak gap and fit analysis rather than real complexity.
Prefer a quick chat? Talk to the Tatvamasi Labs team about your customization plan.
CHAT ON WHATSAPP
