What Does "Odoo Customization" Actually Mean?

A finance director in Jakarta forwarded us two Odoo proposals last month. Both said “fully customized to your business.” The first quote was Rp 120 juta. The second was Rp 780 juta. Both vendors meant something completely different by the word customization, and neither had explained that to the customer.

This is a common situation. The term is used so loosely that it covers everything from “we added a custom field” to “we forked the entire codebase.” Before you can compare proposals or scope an implementation, you need a clearer mental model of what people actually mean when they say it.

The five layers of Odoo customization

Customization is not one activity. It is a stack of progressively heavier interventions. Each layer is a different cost, different risk, different upgrade burden.

Layer 1: Configuration

This is what most businesses actually need, and it is technically not customization at all. You are turning standard knobs the system gives you. Setting up your chart of accounts. Defining product categories. Configuring tax rules so PPN 11% applies correctly. Setting up payment terms, warehouses, user permissions, email templates. Loading your initial data through CSV imports.

A good consultant can do an enormous amount through pure configuration. If you walk into an implementation thinking everything you want is custom code, you will be surprised — usually 70 to 80% of what feels like a “custom requirement” is actually a configuration question.

Layer 2: Odoo Studio changes

Studio is Odoo Enterprise’s no-code customization tool. You can add fields to existing models, change form layouts, rearrange list views, build simple automation rules, and create basic reports without writing Python.

What this is good for: small extensions to existing forms. Adding a “preferred delivery time” field to the customer record. Hiding a column salespeople do not use. Auto-filling a value when a record is created. Building a small approval flow.

What it is not good for: anything that needs custom logic across multiple modules, anything that needs to call external APIs, anything that touches accounting in non-trivial ways. Studio changes also have to be exported carefully if you want them version-controlled, and migrating them between environments is finicky.

Studio is genuinely useful. Just do not confuse it with the heavier kind of customization.

Layer 3: Custom Python modules

This is where real custom development starts. A developer writes Python code that adds new models, extends existing ones, defines new business logic, builds custom workflows, generates specialized reports, and integrates with external systems.

Examples we see all the time:

• A consignment module for a Bandung retailer who works with 200 small suppliers on consignment terms
• A custom commission calculation engine for a distributor whose salesman incentive structure does not match any standard pattern
• An e-Faktur connector that handles the actual API call to DJP and embeds the tax invoice numbers correctly into Odoo invoices
• A Tokopedia or Shopee sync module that pulls orders in, pushes stock and fulfillment back out
• A custom MRP routing for a specialty manufacturing process not covered by the standard Manufacturing app

Custom modules live in their own directory, have their own version control, and survive Odoo upgrades reasonably well if written cleanly. This is the right layer for anything substantial that is genuinely specific to your business.

Layer 4: Core module overrides

When you change behavior of a standard Odoo module — say, you alter how the Inventory module reserves stock, or how Accounting posts entries — you are overriding the core. Done properly through Odoo’s inheritance mechanism, this is acceptable. Done badly, by editing the core files directly, you have just made every future Odoo upgrade a multi-week project.

This layer should be used carefully and only when the standard behavior genuinely does not fit. A common warning sign: vendors who go straight to “we will modify the Sales module” when the actual need could be met by adding logic in a separate module that listens to Sales events.

Layer 5: Forking Odoo

The deepest end. You take the Odoo codebase, fork it, and maintain your own version. This was more common before Odoo’s API stabilized. Today it is almost always the wrong answer. The upgrade path becomes brutal — every time Odoo SA releases version 18, 19, 20, you have to manually merge your fork against their changes. Most companies that have done this regret it within three years.

If a vendor proposes forking Odoo for anything other than truly exceptional circumstances, get a second opinion.

Why the layers matter for cost

A “customized Odoo” implementation at Layer 1 and 2 might cost Rp 100–200 juta and take six to ten weeks. The same words at Layer 3 and 4 might cost Rp 400–900 juta and take four to eight months. The vocabulary is identical. The reality is not.

When you read a proposal, the question to ask is not “does it include customization” but “which layers are involved, and which specific requirements are being addressed at each layer.”

Where Indonesian implementations usually land

For an SME with reasonably normal operations, a healthy implementation usually looks like this:

• Heavy use of Layer 1 (configuration)
• A handful of Layer 2 (Studio) tweaks
• Two to four Layer 3 (custom Python module) additions — typically e-Faktur, marketplace integration, and one or two business-specific modules
• Almost no Layer 4 (core overrides), and only when unavoidable
• Never Layer 5 (forking)

If your proposal looks substantially different from this shape without a clear justification, that is worth a conversation.

A simple test before you commit

For any customization in a proposal, ask the vendor: which layer is this, and why is it needed at that layer rather than the one above? A good Odoo partner will answer this clearly. A vendor who waves their hands or says “everything is custom” is either selling you more than you need, or has not actually thought through the architecture.

If you are trying to decode an Odoo proposal or figure out how much of what you want is actually configuration versus real custom work, an hour-long conversation usually sorts it out. We do those at no cost.