Odoo custom addon development: when you need a module, and how to build it right

"Odoo doesn't do this one thing, we need someone to program it." We hear that a lot. Sometimes it's true. Sometimes the feature is already in Odoo and a setting fixes it. Sometimes there's a ready addon in the Odoo Apps Store that does it.

A custom module is a powerful tool, but it comes with a cost that never goes away: every line of code you add on top of Odoo has to be maintained and upgraded with every new version. So let's go through it in the right order.

The right order: configure, then the Apps Store, then code

1. Try configuration first. Odoo has far more options than it looks like: approval rules, extra fields through Studio (on Enterprise), automated actions, email templates, inventory routes, reordering rules. A lot of requests that reach us as "development" are solved here.

2. Then check the Odoo Apps Store. There are thousands of addons, some excellent, some abandoned. A maintained ready-made module is cheaper than any development, as long as it targets your exact version, the publisher still updates it, and it works on the edition you run (Community or Enterprise).

3. Custom development comes last, but it has its place. It's worth it when:

• The process is what sets your business apart, and bending it to fit the software makes no sense.
• You need to connect to a local or external system that has no ready addon.
• The ready addons do most of the job and get the rest wrong.
• Someone types the same thing in by hand every day and the system could do it.

For the bigger question (Odoo or a fully custom system), see Odoo or a custom system?.

The addons businesses actually ask for

From the work we see, requests fall into a handful of recurring types.

Payment gateway integrations

Buy-now-pay-later and local gateways don't always come ready in Odoo. One from our own work: the Tabby & Tamara for Odoo module we built and ship, which connects instalment payments to the point of sale and invoicing. (The module is ours; it is not affiliated with Tabby or Tamara.)

WhatsApp inside Odoo

One of the most common requests right now: the invoice goes to the customer on WhatsApp the moment it's confirmed, a reminder goes out for an overdue payment, a message with "Approve / Reject" buttons updates the Odoo record directly when someone taps, and a bot sends customers their invoices when they ask for them. We wrote up the whole journey in setting up the WhatsApp API and connecting it to Odoo, and the smart bot side in connecting AI to WhatsApp.

Integrations with other systems

Shipping companies, your online store, your own mobile app, your bank. An API integration moves orders, stock and statuses across without anyone copying and pasting.

Wallet, loyalty and point-of-sale tweaks

A customer balance, points, a special discount rule, a cashier screen with one extra step that fits your branch. Small details on paper, big ones in daily operations.

Approval flows and Arabic printouts

A purchase order that needs a manager's sign-off above a threshold, a quotation in your company's layout, a daily report in Arabic that prints correctly right to left.

E-invoicing adjustments

Some setups need changes to how invoices are issued or what data they carry, so ZATCA requirements and the way you actually work line up.

How a good addon is built

This is the difference between an addon that lives with you for years and one that becomes a liability:

• Never touch Odoo's core code. Every change goes through inheritance (_inherit) and view inheritance. If someone edited Odoo's own files, the first upgrade either wipes their work or stops dead.
• A standalone module with explicit dependencies. The __manifest__.py states exactly what it needs (say account and point_of_sale) and doesn't rely on things being there by accident.
• Access rights from day one. ir.model.access files and record rules, so a branch employee sees their branch's data and nothing else.
• Data migration scripts. When the data shape changes between versions of the addon, a script moves it, not someone editing the database by hand.
• Tests. Automated tests that check the calculation, the approval and the integration still work, and tell you when an update breaks one.
• Your exact version. An addon written for Odoo 16 does not run as is on 17 or 18. And you need to know up front whether you're on Community or Enterprise, because some apps exist in one and not the other.
• Arabic translation and right-to-left layout. Not just translated labels: printouts, reports and forms have to come out properly.
• Documentation. What it does, how it's configured, what to expect, so any developer after us can understand it.

Where bad addons go wrong

If you tried Odoo before and had a rough time, one of these was probably involved:

• Core edits that make upgrading close to impossible.
• Addons that break on the next version because they were written against things Odoo later changed.
• Nobody maintains them. The developer left, and you don't have the code.
• Slow computed fields that recalculate thousands of records every time a screen opens, so the system feels heavy for no visible reason.
• Permission holes from sprinkling sudo() around "to make it work", letting an employee see or change records that aren't theirs.

The wider failure patterns are in why Odoo rollouts go wrong.

Upgrades: custom code is what slows everything down

When Odoo releases a new version, standard apps upgrade with Odoo's own tooling. What always takes the time is custom code: every addon has to be reviewed, adapted to the changes, and tested.

To keep the next upgrade cheap:

• Write less code. Anything a setting can do, don't program.
• Inheritance only, no core changes.
• Tests that run on the new version and tell you what broke.
• One addon per job, instead of one giant module that does everything.

How to brief a developer

Describe the process and the problem, not the screen. Instead of "I want a button here", say: "When an invoice goes over a certain amount, the finance manager has to approve it before it's sent, and today we do that over WhatsApp and memory." That lets the developer suggest the simplest fix, which is sometimes a setting you already have.

And before anything starts, agree on one thing: the code is yours. You receive it in a Git repository you own or can access, with documentation.

Quick questions

Who owns the addon's code?

You should. Put it in the agreement in plain words: you receive the full code and can hand it to any other developer.

Does it work on Odoo.sh, on-premise and Odoo Online?

Odoo.sh and on-premise, yes. Standard Odoo Online (the regular SaaS) does not allow custom Python modules, so if you need one you move to Odoo.sh or your own server.

How long does it take?

It depends on the size of the process and how many systems get connected. A small addon that changes a screen or a report is a different job from a full integration with an external system. Anyone who gives you a timeline before understanding the process is guessing.

What happens when Odoo releases a new version?

You don't have to upgrade every year. But when you do, addons have to be reviewed and tested on a copy before you move. A well written addon upgrades far faster.

How we do it

We start by studying the process and separating what configuration solves from what really needs code. What needs code we build as a standalone module using inheritance, with access rights, tests and Arabic translation, and we try it on a copy of your data before it reaches the live system. At the end you get the code and the documentation.

See our Odoo page and Odoo with e-invoicing, our Tabby & Tamara for Odoo module as an example of an addon we maintain, or book a consultation and tell us which process is wearing your team out.