Odoo Modules: The SME Map of Which to Install, Dependencies, and Over-Install Traps

What an Odoo module actually is (and why 'app' vs 'module' matters)

An Odoo module is a directory of code — data models, views, data files, web controllers, and static assets — declared by an __manifest__.py file. That manifest is the single source of truth for what the module is, what it depends on, and whether it is a standalone application.

The distinction that confuses most buyers: all apps are modules, but only modules with 'application: True' in their manifest are standalone apps. A module can be a behind-the-scenes bridge (no icon, no menu) that exists purely to make two other apps talk to each other.

This matters because the 'app' you click in the Odoo Apps dashboard is rarely a single module. Sale (Sales) looks like one app but its manifest depends on sales_team and product (plus related modules such as payment and delivery) — and Odoo recursively installs every dependency before the target module. Click one icon, install several codebases.

Understanding this gap between 'app' (the marketing unit) and 'module' (the technical unit) is the first step to not over-installing. The rest of this page maps that reality for the SME buyer.

• →Every Odoo module ships a __manifest__.py declaring its name, dependencies, and whether it is an application
• →Only modules with 'application: True' show up as installable apps in the Odoo Apps dashboard
• →Dependencies in the manifest's 'depends' key are technical names (e.g. 'sale', 'account', 'stock')
• →Odoo recursively installs every dependency before the module you actually clicked

The core Odoo modules and what each one does

Here is the scannable map of the foundation Odoo modules an SME actually encounters. One-line purpose, who needs it, and — critically — what it depends on, because dependencies dictate what auto-installs when you switch the app on.

The Odoo dependency chain, explained

This is the single biggest blind spot on the entire 'Odoo modules' SERP. Partner blogs list apps in a feature table and never show the chain — so buyers are surprised when 'Purchase' drags in both Inventory and Invoicing, or when 'Sales' alone does NOT pull in Inventory.

Here is the core chain, drawn from the Odoo developer module reference. Read it top-down: each module needs everything above it.

base -> product -> stock (Inventory)

base -> product -> account (Invoicing / Accounting)

base -> product -> account -> purchase (Purchase needs BOTH stock + account)

base -> sales_team + product (+ payment, delivery-related) -> sale (Sales)

stock + sale -> sale_stock (auto-installed bridge)

purchase + sale -> sale_purchase (auto-installed bridge)

Three things this map tells you: (1) Installing 'Sales' alone does NOT pull in Inventory — you can run a services business on CRM + Sales + Invoicing without ever touching stock. (2) 'Purchase' requires BOTH stock and account, because a purchase order must post to a journal and move stock. (3) When you install two related apps, Odoo auto-installs bridge modules via an auto_install flag.

• →base is the root of every Odoo database — it is always there
• →product sits just above base and is pulled in by stock, account, and sale
• →stock (Inventory) and account (Invoicing) are siblings, both depending on product
• →purchase requires both stock and account — it sits below both
• →sale does NOT require stock — services businesses can skip Inventory entirely
• →Bridge modules (sale_stock, sale_purchase) auto-install when both sides are present

What an SME actually needs: the 4-6 module starter set

The Odoo forum consensus on 'main modules necessary for SME implementation' is consistent: CRM, Sales, Invoicing/Accounting, Inventory, Purchase, and Manufacturing (MRP) for makers. That is a maximum, not a starting point. Below are three SME personas with the minimum module set each one needs — and what each set auto-installs.

Service business (agency, consultancy, professional services): CRM + Sales + Invoicing + Project. No Inventory, no stock, no MRP. This is the lightest viable Odoo for a services SME and it skips the entire product -> stock branch of the dependency tree.

Trader / distributor (wholesale, retail, import): CRM + Sales + Inventory + Invoicing + Purchase. Installing Purchase pulls in both stock and account automatically, so the explicit set is really CRM + Sales + Purchase, with Invoicing and Inventory arriving as dependencies.

Maker / manufacturer (light assembly, fabrication): add Manufacturing (MRP) to the trader set. MRP depends on stock and the manufacturing data layer, so the install order stays clean.

Odoo Studio: the Enterprise no-code wildcard

Odoo Studio is the no-code/low-code app builder bundled with Odoo Enterprise. It lets authorized users add custom fields, redesign views and forms, build new reports, and assemble new mini-apps without writing Python code.

The honest limit: Studio carries an SME a long way — custom fields on a sales order, a tailored Kanban view, a bespoke PDF report — until you hit logic that genuinely belongs in a computed field or a server action. At that point you need a developer, and Studio's no-code customizations become a layer you must maintain alongside any hand-written code.

Studio is Enterprise-only. There is no equivalent in Community, which is one of the most common reasons an SME moves from Community to Enterprise. If your customization needs are limited to fields and views, Studio plus Enterprise can replace the cost of a custom module.

• →Studio adds custom fields, redesigned views, custom reports, and new mini-apps without code
• →It is included only with Odoo Enterprise — not available in Community
• →It covers most no-code needs until you require real computed-field logic or server-side automation
• →Once you hand-write code alongside Studio, you are maintaining two customization layers

Community vs Enterprise: which modules you lose

Odoo Community Edition is free and open-source — you pay only for hosting, implementation, and any custom modules you commission. Odoo Enterprise is subscription-based and is built on top of Community, adding official support, hosting, upgrades, and a set of Enterprise-exclusive apps.

The modules you lose by staying on Community are the differentiators: Studio (no-code app builder), IoT, VoIP, Sign, and Helpdesk are all Enterprise-only. The Odoo Community Association (OCA) maintains thousands of free open-source modules (licensed under LGPL-3 or AGPL-3) that fill many gaps, but OCA modules are community-supported and require self-hosting (Community or Odoo.sh) to run.

The trade-off is straightforward. Choose Community if you have technical resources to self-host, want source-code control, and are comfortable with community support. Choose Enterprise if you want official support, managed hosting, automated upgrades, and the exclusive apps (Studio, Helpdesk, Sign, VoIP, IoT) that matter to your workflow.

What Odoo modules cost (and why edition matters more than app count)

A practical reason the over-installation conversation differs by edition: Odoo Enterprise is all-apps-included pricing, so adding modules does not raise your per-user license cost — but it still raises your performance and upgrade-risk cost. On Community, modules are free, so the only cost of installing is the hidden one.

Odoo Enterprise introductory pricing (as of mid-2026, per the official Odoo pricing page) starts at US$24.90/user/month for the Standard plan and US$49.00/user/month for the Custom plan, both first-year promotional rates; regular rates after the intro period are higher (commonly cited around US$31.10/user/month for Standard). Reported US pricing for the Custom plan has ranged as high as roughly US$76.20/user/month in early 2026, reflecting recent increases. Regional pricing varies — Canada and the UK typically sit between the US and the lower-cost markets, and the Middle East is consistently among the lowest.

The implication for SMEs in our primary markets (Canada, then UK, then US): on Enterprise, every module you switch on is 'free' in license terms but 'expensive' in long-term maintenance. On Community, the same logic applies with zero license cost. In both editions, the right move is to install the minimum set that runs your business.

• →Enterprise includes all apps in one per-user price — adding modules does not change license cost
• →Community is free and open-source — adding modules also does not change license cost
• →Introductory pricing (mid-2026): Standard from US$24.90 and Custom from US$49.00 per user/month; regular rates after year one are higher
• →US Custom-plan pricing has been reported as high as ~US$76.20/user/month in early 2026; regional pricing varies widely

The over-installation trap: what partner blogs won't tell you

Almost every 'Odoo modules' guide on the SERP is written by an Odoo-only implementation shop. Their business model rewards more billable customization hours, so they tend to over-recommend and rarely describe the real cost of installing too many apps. Here is what they omit.

Performance: every installed module loads its code, hooks, and computed fields into each request. More modules means more RAM and CPU consumed on every page load, not just on the screens that use the module. An Odoo database that has been over-installed for years feels sluggish in ways that are hard to undo.

Upgrade breakage: more modules means more dependencies that can break during a version upgrade. Each custom or third-party module must be re-validated against the new Odoo version, and a single incompatible dependency can block a major upgrade (for example, the move to Odoo 19, released September 18, 2025 at Odoo Experience 2025).

Data lock-in: uninstalling a data-filled module is painful. Once real records exist against a module's tables, removing it cleanly is risky and often avoided — which means a module you installed 'just to try' in month one can still be in your database in year three. The remedy is a 2-3 month run-before-adding rule: install the essentials, run the business, and only add a module when you have a documented operational need that the current set cannot meet.

• →Performance: every installed module loads hooks and computed fields into each request, consuming RAM/CPU across the whole database
• →Upgrade breakage: more dependencies means more risk that a single incompatible module blocks a major version upgrade
• →Data lock-in: uninstalling a data-filled module is painful, so 'just try it' modules tend to stay forever
• →Remedy: a 2-3 month run-before-adding rule — install essentials, then add only on documented need

App Store vs OCA: where to get third-party Odoo modules (and where they run)

The Odoo App Store has grown past 40,000 apps — Odoo first positioned it as the biggest business app store when it crossed the 10,000-app mark (overtaking Salesforce AppExchange at the time), and it has roughly quadrupled since. Separately, the Odoo Community Association (OCA) maintains thousands of free open-source modules (LGPL-3 or AGPL-3 licensed). These are two very different sources with different quality and deployment rules.

There is a hard deployment constraint most SMEs only learn the hard way: third-party apps sold on the Odoo Apps Store cannot be installed on Odoo Online unless they are data-only modules (no Python files). If a store app contains Python — and most useful ones do — you need self-hosted Community, self-hosted Enterprise, or Odoo.sh to run it.

In practice: OCA modules are vetted by a community review process and are a good first stop for Community users. App Store modules vary widely in quality, maintenance, and version compatibility — treat each one as a long-term maintenance commitment, not a one-time install.

• →Odoo App Store: 40,000+ apps (it first claimed the biggest-business-app-store title at the 10,000 milestone); OCA: thousands of free open-source (LGPL-3 or AGPL-3) modules
• →Third-party store apps with Python files CANNOT run on Odoo Online — only on self-hosted Community/Enterprise or Odoo.sh
• →OCA modules are community-reviewed; App Store quality varies and each module is a maintenance commitment
• →Treat every third-party module as a dependency you must re-validate on every Odoo upgrade

A phased rollout plan for your first Odoo modules

A phased rollout is the single most effective defence against the over-installation trap. The goal is to start narrow, prove value, and expand only on evidence — not to launch with every app switched on because the partner billed for it.

1. 01
   Phase 1 — Install the 4-6 essentials (weeks 1-6)

   Use the persona table above. Service business: CRM + Sales + Invoicing + Project. Trader: CRM + Sales + Inventory + Purchase. Maker: add MRP. Configure each module against your real processes, migrate clean master data, and train users on the core workflows only.

2. 02
   Phase 2 — Run for 2-3 months on the essentials (months 2-4)

   Do not add anything. Collect feedback from users on what they genuinely cannot do in the current set. The temptation in this phase is to install a module the moment someone asks for it — resist, log the request, and let patterns emerge. A need that survives 8-12 weeks of real use is a real need.

3. 03
   Phase 3 — Add modules only on documented need (month 5+)

   When a documented, recurring operational gap appears, add the module that fills it — one at a time, with a defined owner and success metric. Prefer core Odoo apps first, then OCA modules (vetted), then App Store modules (treat as a maintenance commitment). Avoid adding modules speculatively for a process that does not yet exist.

How Flectic helps you avoid Odoo modules you don't need

Flectic is platform-neutral by design. We implement Odoo and Microsoft Dynamics 365 Business Central for SMEs across Canada, the UK, and the US, so we have no incentive to oversell Odoo modules — doing so would only make our implementations slower and our support harder. The right scope is the smallest scope that runs your business, and that is what we plan to.

Our AI-Accelerated Delivery Framework is designed to deliver implementations up to 3x faster by embedding AI into discovery, process analysis, requirements capture, testing, and documentation. Faster delivery means less time billable by the hour, which removes the structural incentive to pad scope with modules you do not need.

We also stay after go-live. Lifecycle support, optimization, adoption, and continuous improvement are part of how we work — so the modules you launch with are the modules we help you live with. If a phase-3 expansion is warranted, we will tell you; if it is not, we will tell you that too.

• →Platform-neutral: we implement both Odoo and Dynamics 365, so we never oversell Odoo modules
• →AI-Accelerated Delivery Framework designed to deliver up to 3x faster — less billable-hour incentive to pad scope
• →Phased scope: start with the 4-6 essentials, expand only on documented need
• →Lifecycle support after go-live: optimization, adoption, and continuous improvement as standard