Publishing a Module on the Odoo Apps Store

The repository is the publishing mechanism

There is no upload form. You connect a public repository to your Odoo account, and the store scans it.

The branch model is the part to internalise: branch names correspond to Odoo versions. A module on a branch named 19.0 becomes the Odoo 19 listing, the same module on 18.0 becomes the Odoo 18 listing, and they are separate listings with separate prices and separate download counts.

So supporting three versions means maintaining three branches containing three ports of the same module. This is not a detail, it is the entire shape of the ongoing work.

Before you list anything

It installs on an empty database. Not on your development database, which has been through twenty upgrades and contains records your data files quietly depend on. A clean install is where load-order bugs surface, and it is what a buyer will do.

It uninstalls cleanly. People uninstall modules while evaluating them. A module leaving broken views or orphaned records behind is a bad first impression, and an override on a core model that assumes its own tables exist can break the uninstall itself.

Access rights exist. The most common cause of a support ticket saying "nothing happens" is a model with no line in ir.model.access.csv, working fine for the administrator who tested it.

The manifest is honest. Explicit license, correct version in the full series form, depends listing exactly what is used. A dependency on an Enterprise-only module makes your app unusable on Community, and that needs saying in the listing rather than being discovered after purchase.

The licence matches the price. LGPL-3 for free, OPL-1 for paid. A paid module declaring an open source licence in its manifest is a contradiction nobody else is going to resolve.

The listing is the product

The code is what they buy. The listing is what makes them buy it, and it is where most first-time publishers underinvest.

Screenshots are the single highest-value asset. Buyers scroll before they read. Capture real screens with plausible data rather than demo records called Test Test, and show the feature rather than the settings page.

The description answers one question first: what problem does this solve. Not what it does. A feature list is what somebody reads after they have decided the module is relevant, and the first paragraph is what decides that.

Say what it does not do. Counterintuitive and it works, because the refunds and one-star reviews come from mismatched expectations rather than from limited scope. A module that says plainly what it excludes gets fewer disappointed buyers.

Name it for search. The store has its own search and most discovery happens through it. The name is the strongest signal you control.

Version support is the real commitment

This is the decision that determines whether publishing is sustainable.

Each new Odoo version means porting every module you maintain. Ten modules across three supported versions is thirty listings, and each needs the port, a test pass and a release. That is a recurring annual cost that arrives whether or not the module sold anything that year.

Two things follow. Support fewer versions than you think you should, because dropping one later disappoints existing buyers while never adding one costs nothing. And write modules that port easily, which means the ordinary discipline: inherit rather than replace, call super(), keep the surface narrow. The coding standards checklist is the same list that makes a module cheap to port.

Support is part of the product

Every buyer can contact you, and a listing with unanswered questions on it converts poorly.

The pattern that works is answering quickly and publicly, since the answers accumulate as evidence the module is maintained. The pattern that does not is treating a low-priced module as low-obligation: buyers do not scale their expectations to your price.

Budget for it before listing. A module that sells well generates support work proportional to sales, which is the good problem, and it is still work.

Whether to publish at all

Publishing suits a module that solves a general problem, is worth maintaining regardless, and is not tied to one customer's process.

It suits a bespoke module poorly. Client-specific work carries assumptions that make no sense elsewhere, and generalising it is usually a rewrite rather than a cleanup.

The honest test is whether you would keep the module working for the next three Odoo versions even if it sold nothing. If the answer is no, publishing converts a finished project into an open-ended obligation.