Custom Odoo Modules: When You Need One and What It Costs

A custom Odoo module is one of those things that sounds expensive until you compare it to the cost of working around its absence for two years. It also sounds cheap until you discover what good ones actually take to build. Most of the bad decisions we see come from estimating either direction without anchoring to specifics.

This piece is the version we walk clients through when they ask “do we really need a custom module here, and what should it cost?”

What counts as a custom module

A custom Odoo module is a Python package that lives inside your Odoo installation and adds or extends functionality. It might define new models, add fields to existing ones, build new business logic, create custom screens and reports, or wire in external APIs. It uses Odoo’s framework — ORM, views in XML, security rules in CSV — but the code is written specifically for your business.

A custom module is more than a Studio tweak. It is also less than a fork of Odoo. The distinction matters because the cost, risk, and maintenance profile of each is quite different.

When you actually need one

The question is not “would a custom module be nice to have” but “does the gap between standard behavior and what we need create real ongoing pain?”

Real pain usually looks like:

• A process the business does dozens or hundreds of times a day where the standard module does not fit the workflow
• A regulatory requirement Odoo does not ship with — e-Faktur, specific BPJS reporting, certain DJP reports
• An integration with an external system that has no off-the-shelf connector for your use case
• A pricing, commission, or accounting rule that is genuinely unique to your business and central to how you operate
• A reporting need that goes beyond what the standard dashboard library produces

What it does not look like:

• A field someone wants on a form that is rarely used
• A nice-to-have automation that saves five minutes a week
• A “report we always had in Excel” that nobody can actually explain the rules of
• A workflow the team thinks they prefer but has not actually tested in standard Odoo

The second list is where most over-customized implementations come from. People customize from imagination, not from observed pain.

A worked example: consignment for a Bandung retailer

A clothing retailer in Bandung came to us with a problem. They worked with about 200 small suppliers on consignment — the suppliers’ products sat in the store, the retailer only paid when items sold. Standard Odoo treats inventory as owned. Consignment items show up as stock the retailer paid for, even though they have not.

The pain was real and constant. Every month the finance team spent four full days reconciling consignment payouts manually in Excel. Stock reports were wrong because they included consignment goods. Procurement decisions were skewed.

The custom module did three things: marked products as consignment-eligible, tracked sold-versus-unsold consignment items at the SKU level, and generated a per-supplier payout report on demand. About six weeks of work, roughly Rp 75 juta. Saved four finance days a month and produced accurate stock reports immediately. The payback was four months. Three years later the module is still in use, has survived two Odoo version upgrades with minor adjustments, and no one questions whether it was worth building.

That is what a “yes” to a custom module looks like. Specific pain, measurable saving, clear scope.

The cost ranges

What an Indonesian SME should actually expect to pay for a custom Odoo module, in 2026 figures:

Small module — Rp 20 juta to Rp 50 juta

A simple extension. New fields, simple views, a small report, light automation, maybe a small computed field. Roughly one to two weeks of developer time. Examples: custom approval flow for purchase orders above a threshold, a custom field set on the customer record with conditional visibility, a small custom report combining data from two existing modules.

Medium module — Rp 50 juta to Rp 150 juta

Real custom logic. New models, multi-screen workflows, a few integration points, custom reports, security and permission rules. Three to eight weeks. Examples: a specialty manufacturing routing module, a consignment module like the one above, a custom field service scheduling module, an integration with one external system (a logistics provider’s API, a single marketplace).

Larger module or module suite — Rp 150 juta to Rp 400 juta

Substantial business logic that touches multiple modules. Two to four months. Examples: a full multi-marketplace integration covering Tokopedia, Shopee, and Lazada with order sync, stock sync, and fulfillment; a custom commission engine for a 50-salesperson distributor; an e-Faktur integration that handles the DJP API end-to-end including error and reconciliation flows.

Heavy custom build — Rp 400 juta to Rp 1 miliar plus

This stops feeling like “a module” and starts feeling like “a system built on top of Odoo.” Multiple interlocking modules, deep integration with several external systems, custom UX across many screens. Four months and up. At this scale the question of “is this really one custom module or should we be building a separate application that talks to Odoo” is worth asking honestly.

What drives cost up

Five things consistently inflate Odoo module costs:

• Unclear requirements. Every clarification round during development costs more than getting it right upfront.
• Touching accounting. Anything that posts to journal entries needs careful design, careful testing, and careful audit trail. Accounting customizations cost more per line of code than anything else.
• Multi-company or multi-currency. Both add complexity in every layer.
• Integration with external systems that have poor APIs. Half the cost of a marketplace integration is handling the platform’s rate limits, schema quirks, and silent failures.
• High data volumes. A module that works fine for 1,000 records a day might need careful query optimization at 100,000. The work is different at scale.

How to keep cost honest

A few practical moves:

• Get the requirements written down before development starts. Vague requirements are the single biggest cost driver.
• Phase the work. Build the smallest version that solves the actual pain, then extend.
• Insist on the module living in version control from day one, not on the production server’s filesystem.
• Make sure the implementation can survive Odoo’s annual version release. Ask the vendor specifically how they handle upgrades.
• Budget 15 to 20% of the build cost annually for maintenance and version-upgrade work.

A simple decision frame

Before you commission a custom module, write down three things on one page:

1. What specific pain is this solving, in concrete terms with numbers if possible?
2. What is the minimum scope that addresses that pain?
3. What is the value of solving it, per month?

If you cannot fill in all three lines clearly, you are not ready to build it. If you can, you have an answerable cost-benefit question and a vendor can give you a real quote.

If you are weighing whether a specific customization is justified, or want help separating which parts of your wish list are genuinely module-worthy, an hour-long conversation usually clarifies the call. We do those at no cost.