Evaluating Odoo Third-Party Apps

What counts as a third-party Odoo app

Odoo is modular by design: every feature you use — Sales, Inventory, Accounting — is itself an addon (module). The Odoo Apps Store at apps.odoo.com is the official marketplace where anyone can publish modules, and as of this writing it indexes tens of thousands of apps (commonly cited in the 40,000–80,000+ range depending on filters and mirrors), browsable by category and sortable by Relevance, Best Sellers, Ratings, Downloads, Purchases, Newest, and price. Alongside Odoo S.A.'s own first-party apps and verticals, the store hosts modules from independent vendors and mirrors of community-built modules.

Important market reality for 2025–2026 buyers: listing on the App Store is not the same as a mandatory technical security audit. Odoo moderates for legal infringements and reported security issues, and publishes quality guidelines, but independent partners and forum threads repeatedly note that pre-publication code inspection is not the default control. That is why evaluation frameworks, not star ratings alone, decide whether a module belongs in production.

Third-party Odoo apps fall into three practical buckets, and knowing which bucket a candidate sits in is the first evaluation step. The first is the commercial App Store module: a paid (or freemium) module sold through the store, where you typically receive the code on purchase and a licence restricts redistribution. Listings show a euro price, a rating, a ratings count, and a download count — the Shopify Odoo Connector from Emipro and Dashboard Ninja from Ksolves are recognizable examples of paid, top-selling modules.

The second bucket is the Odoo Community Association (OCA): a Swiss non-profit that coordinates open-source Odoo modules, peer review, CLA-gated contributions, and open upgrades. OCA reports on the order of 20,000 modules across many versions, with contributors and members spanning dozens of countries. Modules are free, typically LGPL-3 or AGPL-3, hosted on GitHub under github.com/OCA, and often mirrored free on the Apps Store. Well-known OCA modules such as audit, stock disallow negative, and base report xlsx appear among the most-downloaded store listings under authors like Akretion, ACSONE, Tecnativa, and LasLabs alongside OCA attribution.

The third bucket is bespoke or vendor-direct modules — code written or handed to you outside the store, installed from the file system on Odoo.sh or on-premise rather than through the in-app Apps menu. This guide focuses on evaluating the first two, because that is where the volume and the risk live; bespoke modules are covered under custom module development, and light field-or-view tweaks often belong in Odoo Studio rather than a new third-party dependency.

Why evaluation matters: the upgrade-safety problem

The single most expensive property of any Odoo module is its version compatibility, and this is the reason a framework exists rather than a casual 'install the top-rated one.' Odoo releases a major version roughly once a year and provides standard support — helpdesk, bug fixes, and security updates — for each major version for three years. Beyond that, extended support is available only for a mandatory additional fee, and only where feasible. Official documentation for Odoo 19 shows the cadence clearly: Odoo 19.0 (released September 2025, standard support planned through September 2028), Odoo 18.0 (October 2024 to September 2027), and Odoo 17.0 (November 2023 to September 2026).

On top of the yearly majors, Odoo publishes intermediary SaaS versions every two to three months that exist only on Odoo Online and are not eligible for extended support. You can see this in the store itself: industry apps published by Odoo S.A. carry version strings like saas-19.1 or saas-19.4, marking them as Odoo Online-only, while general third-party modules target a major branch such as 19.0 or 18.0. Reading those version strings correctly is the first concrete evaluation skill, because a module built for a SaaS-only branch will not run unchanged on an 18.0 on-premise database.

Migration practitioners report that third-party estates are the usual blocker, not core Odoo. Typical audited deployments carry at least a dozen third-party modules; medians near forty are common, mixing OCA addons, old App Store purchases, and custom code whose original author has left. Odoo 19 continues to change the ORM surface, asset pipeline, and web/OWL stack, so any module that inherits views, overrides sale.order / account.move / stock.picking, or ships legacy JS can fail silently or loudly on upgrade. Evaluation, done up front, is how you avoid strapping a time bomb to your upgrade roadmap.

The goal of the rest of this guide is to make that judgment reproducible: five independent lenses, a scored checklist, an explicit red-flag catalogue, and a decision matrix that compares OCA, commercial App Store modules, and custom builds on upgrade risk and total cost of ownership — not download count.

The five lenses of evaluation

A reliable evaluation separates five independent questions and scores each one on its own merits. They are: Compatibility and version targeting — will it run on my exact Odoo major (and edition)? Maintenance and support — is it alive, who fixes it when it breaks, and what is the response path? Code quality and security — is the source safe, scoped, and free of known anti-patterns? Business fit and dependency hygiene — does it solve my real problem without bloating the estate or chaining fragile third-party depends? Total cost of ownership — what will it cost over three years, including upgrade tax, not just at checkout?

2026 diligence adds explicit checks that buyers still skip: exact version pin (19.0 vs '17+' marketing), public changelog and last-update date relative to your branch, written support SLA or living issue tracker, dependency graph (including Python packages and other third-party modules), and security posture (access rights, RPC-callable methods, SQL/XSS patterns). None of these is optional for modules that touch accounting, inventory, identity, or e-commerce connectors.

Treating these as separate lenses matters because a module can ace one and fail another. A wildly popular free module with tens of thousands of downloads can still be abandoned on an old branch (compatibility fail). A slick, well-supported paid module can ship a SQL-injection vulnerability (security fail). A perfectly secure, well-maintained module can duplicate functionality you already own (business-fit fail). The discipline is to never let a strong rating in one lens substitute for evidence in the others.

For each lens, the evaluation produces one of three verdicts: pass, conditional (acceptable if you mitigate a specific risk), or fail. A fail in compatibility, security, or maintenance is usually a hard stop, because those risks compound at upgrade time. A conditional in cost or business fit is negotiable — you may accept a recurring fee or a small overlap if the module is clearly the best fit. The checklist and red-flag sections turn these five lenses into a concrete go/no-go process you can apply in about ten minutes per module before any sandbox install.

Compatibility and version targeting

Compatibility is the first filter and usually the fastest to check. Every module on the store declares the Odoo version it targets, visible in its URL and listing — for example a module at /apps/modules/19.0/... targets the 19.0 major branch, while one at /apps/modules/saas-19.1/... targets a specific Odoo Online SaaS version. Before anything else, confirm the module has a version of itself published for your exact branch. If you run 18.0 and only a 16.0 build exists, that is a hard compatibility warning even if the author claims backward support. From Odoo 14 onward, major versions are sold as separate store products; buying 18.0 typically does not entitle you to 19.0 unless the vendor says so in writing.

Edition matters too. Odoo comes in Community and Enterprise editions, and modules can depend on Enterprise-only models (the Enterprise accounting and reporting stack being the common one). A module that depends on Odoo Enterprise apps will install on Enterprise but fail or behave incorrectly on Community. Conversely, OCA and many free store modules are written against Community and work on both — the popular Community accounting kits exist precisely to backfill what Community lacks. If your edition is Community, confirm the module's dependencies are all satisfiable without Enterprise.

Finally, account for your hosting model. On Odoo Online (SaaS), you can only install modules through the in-app Apps menu — that is, modules listed on the store and compatible with your hosted version — and you cannot upload arbitrary custom or vendor-direct Python modules. Odoo.sh and on-premise give you full control over the addons path and therefore over what you install via Git, submodules, or the store's Deploy to Odoo.sh flow. A module that requires manual file placement, system packages, PostgreSQL extensions, or a patched Odoo core is automatically disqualified on Odoo Online, and is a yellow flag even on Odoo.sh because Odoo.sh restricts system packages and lists some known-incompatible modules (for example certain queue_job configurations can violate acceptable-use performance limits).

Maintenance and support signals

Maintenance is where most modules quietly fail, and it is the lens most buyers under-weight. The signals to read are: the last-updated date relative to the current branch, the breadth of version coverage (does the author maintain the module across 17.0, 18.0, and 19.0 simultaneously, or only one?), the author's track record and catalogue size, the presence of a public changelog or issue tracker, and whether paid support or an upgrade service is offered with a response commitment. A module whose last update predates the branch you are about to leave is effectively abandoned, regardless of its rating.

Author reputation is a strong proxy. OCA modules carry the governance of a non-profit that positions itself explicitly as a marker of quality in the ecosystem, with peer review, automated tests on many repositories, and a CLA-gated contribution process; when one OCA maintainer steps back, another often takes over the repository. Established vendors with broad catalogues (Cybrosys, Emipro, Ksolves, Akretion, and others visible in the top charts) have a commercial reason to keep their modules current across versions. A single-module publisher with no other apps and no visible support channel is a concentrated risk: if that one person stops maintaining it, you inherit the maintenance burden entirely.

Ask vendors hard questions before purchase: is the next major-version port included or billed separately? What is the support channel and expected first-response time? Can they show a 19.0 (or your target) changelog, not just a marketing claim of 'compatible with latest Odoo'? For OCA, open the GitHub branch for your major, check recent commits, open issues, and CI status. Modules that pass this lens are the ones that will not become the blocker on your next version upgrade.

Code quality and security audit

Because an Odoo module runs in the same process as your core apps, against the same ORM and the same PostgreSQL database, its code quality and security are your problem the moment you install it. The good news is that the source is almost always available — OCA modules are open source on GitHub, and commercial store modules ship their Python and XML to you on purchase — so a real audit is possible. The bad news is that most buyers never read it, and the App Store does not substitute a mandatory pre-publish code review for that work. The audit targets three areas: the manifest and dependency graph, the access-control declarations, and the dangerous patterns Odoo's own security documentation warns against.

Start with the manifest (__manifest__.py). Read the depends list: it defines both install order and the inheritance graph, and every dependency is another module you must also install and maintain. A module that depends on five other third-party modules multiplies your maintenance surface sixfold. Check that the declared version string is meaningful (for example 18.0.1.2.0 rather than 1.0), because Odoo parses it to decide when to run data migrations, and a lazy version string signals a lazy module. Confirm the licence is declared and compatible with your use (more on this in the cost lens).

Next, inspect security. Odoo's security model has two data-driven layers — access rights in ir.model.access.csv granting CRUD on a whole model, and record rules (ir.rule) applying row-level filters via Python domains — plus field-level access through the groups attribute. A module that adds custom models but ships no ir.model.access.csv entries is the single most common cause of AccessError on first use, and a module that grants overly broad access (for example write access to sensitive models for every user) is a data-leakage risk. Both are visible by reading the module's security/ folder.

Finally, scan for the security pitfalls Odoo's developer reference calls out explicitly. Public methods (those not starting with an underscore) are callable via RPC with attacker-chosen parameters, and the record and arguments on such methods cannot be trusted because access control is only verified during CRUD operations — so a module that mutates state or escalates privileges inside a public method without its own checks is vulnerable. Direct use of the database cursor with Python string concatenation (+) or %-interpolation to build SQL is a SQL-injection vector; the safe pattern is to use the ORM or parameterised queries through psycopg2. And t-raw in QWeb templates, used to inject unescaped content, is a recurring cross-site scripting (XSS) vector. The presence of any of these patterns in a module you are evaluating is a security fail unless you can see the mitigation. Tests in a tests/ directory and, for OCA, green CI on the target branch are positive signals — they indicate the author validated logic rather than shipping by trial and error.

Business fit and dependency hygiene

Business fit is the lens that protects you from installing capability you do not need. The store makes it easy to grab the most popular module in a category, but popularity measures appeal, not fit. A high-rated generic dashboard app is worthless if your bottleneck is EDI compliance; a niche compliance module with a small install base may be the highest-ROI purchase you make. Frame the question against your actual process gap, not against the store's ranking, and prefer the smallest module that closes the gap over the broadest suite that overlaps it. Also check whether Odoo core or Enterprise already absorbed the feature in your major — community modules from older versions often become first-party later.

Dependency hygiene is the structural version of the same discipline. Every module you add is an upgrade-surface and a potential conflict, so the target is the smallest extension estate that covers the real need. Watch for dependency chains — module A depends on B which depends on C — because you are really adopting the whole chain, and the weakest maintainer in it sets your maintenance ceiling. Watch for overlap: two modules that both override sale.order or both extend the same view can collide on upgrade or produce unpredictable behaviour, and Odoo composes extensions in dependency order rather than detecting conflicts for you.

A useful rule of thumb is to maintain a short, documented inventory of every third-party module in your database, with origin (OCA / App Store / custom), exact installed version or commit pin, the reason it was installed, and the owner responsible for it. When a new candidate appears, the first question is whether an existing module already covers the need, or whether a configuration change, an Odoo Studio tweak, or a small customisation would avoid a new dependency entirely. The goal is not minimalism for its own sake — it is keeping the estate small enough that every version upgrade is survivable.

Total cost of ownership and licensing

Total cost of ownership for a third-party Odoo module is rarely the sticker price. OCA modules are free and permissively or copyleft-licensed; many store modules from community-oriented vendors are free as well; and paid commercial modules range widely — observed store prices include small utilities around €17 (an RFID/PIN login module), dashboards and connectors around €500 (a Shopify or WooCommerce connector, a dashboard suite), and vertical bundles higher still. But the recurring costs — install and configuration hours, version upgrades, support retainers, and the licence's effect on your own code — usually dwarf the initial fee.

Budget a three-year line item, not a one-time cart total. Typical components: (1) licence or purchase price per major you will run; (2) partner or internal hours to install, configure, and train; (3) upgrade tax at each major — re-buy, re-validate, or re-port — often the largest line if the vendor bills ports separately; (4) support SLA or emergency firefighting when the module blocks production; (5) opportunity cost of keeping a leaner stack or using Studio/core instead. Partners who audit large estates treat abandoned App Store modules as high-effort replacements (days of work) compared with OCA modules that already have a 19.0 branch and passing tests (often under an hour to pin and retest).

Licence type is a cost you pay in obligation, not euros, and it matters for any module you might extend. OCA modules are typically AGPL-3 or LGPL-3: LGPL-3 keeps a module compatible with Odoo Community and lets you link it without copyleft infecting your own code, whereas AGPL-3 is a strong copyleft that can require you to release derivative works if you expose the combined work over a network. Commercial store modules usually ship under Odoo Proprietary License (OPL) or another proprietary licence that forbids redistribution and may restrict modification. Dual-licence traps appear when a free demo module and a paid unlock module differ in terms, or when an OPL module quietly depends on an AGPL helper — confirm the full dependency tree's licences before you build on them.

Ask the vendor up front: is the version-to-version upgrade included in the licence, or billed separately? Is there a support tier with a response-time commitment, or only a community forum? For OCA modules, the cash price is zero, but the cost is internal — your team or partner absorbs maintenance — and that cost should be estimated honestly. A module that is free to acquire but unmaintained on your next branch can cost more than a paid, supported alternative when upgrade week arrives.

Red-flag patterns that should stop an install

Star ratings and download counts do not catch the failure modes partners see repeatedly. Treat the patterns below as hard stops or severe conditionals. One red flag may be mitigable with a sandbox trial and a written vendor commitment; three or more usually means walk away and solve the need with OCA, Studio, core, or a controlled custom module.

Abandoned version ports. The listing still sells a 16.0 or 17.0 build while you are on 18.0 or 19.0, or the author 'migrated' by renaming the version without a real changelog. Cheap paid modules in the low tens of euros are frequently reported as half-ported: menus appear, core methods break, or dependent features silently no-op. If the last meaningful update predates your current major, assume you will own the port.

Hidden dependency graphs. The store page describes a single app, but __manifest__.py depends on other third-party modules, unpaid 'base' packages from the same vendor, or Python libraries that need system packages Odoo.sh will not install. On Odoo.sh, third-party modules that require unsupported PostgreSQL extensions or known-problematic async patterns can be incompatible by design. Map the full graph before you buy.

Core model lock-in. Modules that heavily override sale.order, stock.picking, account.move, or shared web assets create structural upgrade debt. When Odoo changes those models in a major, your module does not automatically follow. If two vendors both inherit the same method, the last one loaded wins and the other can fail without a clean error at install time.

Dual-licence and refund traps. A free shell plus a paid unlock, OPL terms that forbid the customisation you need, or refund windows that expire before real production use. Support that lives only on a personal email with no SLA is the same risk as no support. Buy only when upgrade ports and support terms are explicit.

Uninstall residue and ghost modules. Poor modules leave ir.model data, views, or automated actions behind after uninstall, or the filesystem addon is deleted while ir.model.module still shows installed — classic ImportError on restart. Always trial uninstall on a copy. Inventory audits before upgrades should flag installed modules with no matching directory on disk.

Complexity disguised as features. Mega-suites that add menus, automated actions, and cron jobs far beyond the stated gap. Prefer a thin module that does one job well. If the same outcome is achievable with Odoo Studio, standard configuration, or a small custom module you control, the 'feature-rich' store app is often a long-term liability, not a bargain.

A practical evaluation checklist

The framework is only useful if it is fast to apply. The checklist below operationalises the five lenses into a ten-minute go/no-go assessment for any candidate module. Work through it in order — compatibility and maintenance are cheap to check and disqualify most weak candidates early, which saves you from investing audit effort in modules you will reject anyway. Record the verdict per lens and require a pass on compatibility, maintenance, and security before proceeding to a trial install.

If a module passes every lens, the final step is a sandbox trial before any production touch: install it on an Odoo.sh branch or a neutralised copy of your database, exercise it against representative data, and confirm behaviour, performance, and uninstall cleanliness before promoting it. Never install an unvetted third-party module directly into the database your business runs on — the cost of a bad module discovered in production is always higher than the cost of a staging trial.

OCA vs App Store vs custom: where each fits

Once a candidate passes evaluation, the meta-question is whether the third-party route is even the right one — and the answer depends on how generic the need is. The Odoo Apps Store and the OCA are the natural first stop for generic, well-served needs: a payment acquirer, a country-specific report, a barcode variant, a dashboard, an e-commerce connector. For these, a maintained store or OCA module is faster and cheaper than building, and the ecosystem has already absorbed the version-maintenance burden across many users.

The custom module is the right answer when the need encodes genuine differentiation, a proprietary integration, or business logic too specific for any vendor to maintain — a custom fulfilment flow spanning sales, inventory, and accounting, or an integration with a proprietary warehouse system. Between the poles, Odoo Studio covers field-and-view tweaks that do not need their own version-controlled module. The trade-off in every case is total cost of ownership, and the dominant cost is version compatibility: owning the code means owning every upgrade and every migration script, while buying means depending on the vendor's or community's commitment to the next branch.

Use the matrix below as a decision aid, not a religion. Prefer OCA when you want auditable open source, multi-maintainer longevity, and free licence cost, accepting that install is Git/addons-path oriented and support is community-paced. Prefer commercial App Store modules when a vendor has a clear SLA, a living multi-version catalogue, and a connector or vertical you will not maintain yourself — and still run the five-lens audit. Prefer custom when no maintained option fits, and only after checking Studio and core. Prefer walk-away when red flags stack, even if the demo looks polished.

The decision rule that holds up in practice is to buy or adopt OCA when the need is generic and a maintained module exists for your branch, and to build when no vendor or community will maintain the logic for you. Companion material on Odoo version upgrades, Odoo.sh hosting, Odoo Studio customisation, and custom module development covers the adjacent paths — but the evaluation discipline above applies to all of them, because every module, bought or built, eventually faces the same version gate.

Frequently asked questions