Buy from the Odoo Apps Store or build it? How to vet a module before you pay

You search the Odoo Apps Store and find a module that does exactly what you asked a developer to quote for, at a fraction of the price. Easy decision.

Often it is the right one. But two years later the same module can be what holds up your upgrade, or what breaks the till's end of day close for reasons nobody can find. The store price is the smallest part of what a module costs. The real cost is who keeps it working on your version, and on the next one.

In our guide to custom Odoo add-ons the order was: configure, then the Apps Store, then code. This post is about the middle step: what to check before you pay, and when building is the better call.

First: can you install third-party apps at all?

If you are on Odoo Online, the standard SaaS you subscribe to on odoo.com, stop here. The Odoo Apps sales conditions say third-party apps install on Odoo.sh and on-premise, not on Odoo Online, and list a database hosted on Online among the cases that are not refunded.

So the first decision is not which module. It is whether you stay on Online and work with what it offers, or move to Odoo.sh or your own server. That move has its own cost; do not make it for one module.

Version: every version is a separate purchase

From Odoo 13 onwards, each version of a module is sold separately. A module bought for 16 does nothing for a 17 database, and "bought the wrong version" is another case the store does not refund.

Your exact version sits at the bottom of the Settings page in Odoo, along with whether you run Community or Enterprise. The module's store page has a version selector. Read the whole list, not just your version:

• Is it published for the latest Odoo? If the list stops a few versions back, the publisher probably stopped too.
• Upgrading next year? Check it exists for the version you are moving to, because you will buy it again for that one.

Community or Enterprise

The store page has an Odoo Apps Dependencies section: the apps the module needs to run. If any of them exists only in Enterprise, it will not install on Community, however good the description sounds.

The reverse catches people too. Odoo's own WhatsApp app is Enterprise only, so the store carries plenty of WhatsApp modules aimed at Community. Install one of those on Enterprise and you have two ways of doing one job, both changing the same screens. We covered that split in Odoo WhatsApp notifications.

Who keeps it alive?

The Odoo Apps FAQ is plain about it: support comes from the publisher, not from Odoo. The publisher should fix bugs that stop advertised features from working and help with configuration; customisation and new features usually cost extra. Odoo also says it does not review every module, and removes one once it finds stolen code, malware, undisclosed features or unauthorised data collection.

So before you buy:

• Who is the publisher? A company with a website and a support channel, or a name with no trail?
• Read the discussion on the module page. Does the publisher answer, and when did they last?
• Send one technical question before paying. Something like: "What happens to a payment your module recorded if I cancel the invoice afterwards?" The answer is a preview of their support.
• Check the licence. Under OPL-1, the Odoo Proprietary License, you may not publish, distribute or sell the module, modified or not. LGPL-3 is far more permissive. Either way you download the module's own files, which you can normally read, and that protects you if the publisher disappears: another developer can pick it up.

Read the code, or have someone read it

The store page shows Lines of code. It is not a quality score, but it is a hint. Thousands of lines to add one field and a report: what is the rest doing? A full payment integration in a hundred lines: where is the error handling?

If you have a developer or technical partner, this is what we open first:

• __manifest__.py: the version, the apps it depends on, and external_dependencies, Python libraries the server must have, which matters on Odoo.sh.
• Overrides of core methods such as create, write or posting an invoice. One that never calls super() silently swallows Odoo's behaviour, and that of every other module extending the same method.
• sudo() everywhere, and raw SQL built by string formatting. The first bypasses access rights. The second invites SQL injection and skips every rule the ORM enforces.
• Access rights: a line in ir.model.access.csv for every new model, and record rules if you run several companies.
• Calls to outside servers the description never mentions, such as a licence check that phones the publisher.
• Obfuscated code. If you cannot read it, you cannot maintain it.
• A tests folder and an i18n/ar.po file. Having them proves little. Missing them says a lot.

Test on a copy, never on the live database

Never install anything on the database your team works in. Take a copy (a staging branch on Odoo.sh, or a duplicated database on your server), install there, and run the whole process with real data: the invoice, the return, closing a POS session. Do it as an ordinary user, not as the admin who sees everything.

Then test uninstalling it. An uninstalled module takes the fields and tables it added with it, data included. Know what you would lose before you build on it.

Test early for another reason. Under the store's conditions, refund claims are allowed within the first two months after purchase, opened with the support button on your order page, the only channel where the refund clock runs. The publisher has 15 days to settle, then either side can ask Odoo to step in. You are refunded for a bug that stays unfixed, a missing advertised feature, or a module that will not install on the version it claims. "It works, it just does not suit us" is not refunded.

What breaks on upgrade

Odoo's upgrade documentation says a database with custom modules cannot be upgraded until those modules exist for the target version. A store module is in the same position as any code that is not Odoo's own: it waits for its publisher.

The changes are not cosmetic. Odoo 17 removed attrs and states from views and replaced name_get; Odoo 18 renamed tree views to list. The point of sale front end changes a lot between versions, so anything touching the till needs real work at every upgrade. A publisher who maintains the module does that work. One who does not leaves you stuck where you are.

When to build instead

Buying wins most generic cases: a payment provider, a report, a common integration. Building wins when:

• You would have to change the module heavily. You now own a modified copy of someone else's code, and the publisher's next update overwrites your changes.
• The process is what sets you apart, and you will not bend it to fit a module.
• Nothing exists for your version, or what exists fails the code checks above.
• You need a local system connected that nobody on the store supports.

A middle path we use often: buy the module as it is, and put any change in a small separate module that inherits from it (_inherit), never editing its files. The publisher's updates keep reaching you and your changes survive them. For the bigger question of Odoo versus a fully custom system, see Odoo or a custom system?.

What a maintained module looks like: one of ours

Tabby & Tamara for Odoo is a module we built and publish on the Odoo Apps Store. It connects instalment payments to the online shop, the point of sale and invoices. (It is ours, and it is not affiliated with Tabby or Tamara.) It shows the kind of answers to look for in any module:

• A branch for every release from 14.0 to 19.0, on Community and Enterprise.
• LGPL-3, with Python source you can read, modify and extend.
• Full and partial refunds from the Odoo back office.
• A log of API requests, with secrets redacted.
• Written setup guides and a known support channel.

Comparing the providers themselves? See payment gateways in Saudi Arabia.

Quick questions

Are free modules safer?

Free does not mean maintained, and paid does not mean sound. Modules from the OCA (Odoo Community Association) have one advantage: changes are reviewed by contributors other than the author, and each Odoo version has its own branch in their repositories. The checks above still apply.

I bought a module for 16 and we are upgrading. Do I pay again?

Under the store's conditions, from Odoo 13 onwards every version is sold separately. Put it in the upgrade budget from the start.

The publisher has vanished. Now what?

You have the code. A developer can review it, maintain it and port it to new versions, and that is when you find out whether it was written well.

How we do it

When a client is weighing up a store module, we vet it before they pay: version, dependencies and the code itself. Then we install it on a copy of their data and run their real process through it. If it holds up, we install it and keep any change in a separate module on top. If not, we build it properly.

See our Odoo page and Odoo with e-invoicing, or book a consultation and send us the link to the module you are considering.