Most of Odoo is addons. Sales, Inventory, Accounting and even the web client (the web module) are folders with the same shape as the one you’d write for a single customer. That’s why a custom addon can change almost anything: it plugs into the same loading mechanism the standard apps use.
Addon, module or app
The words overlap, and the docs use them loosely. “Addon” and “module” mean the same thing. Odoo keeps its source in folders called addons and the server option is --addons-path, while the Apps screen talks about modules. An “app” is a module whose manifest sets application to True. Apps show up under the default Apps filter; technical modules only appear once you clear it, which is the usual reason people think Odoo can’t see their new module. Most customization addons aren’t apps and shouldn’t pretend to be.
What sits in the folder
Two files are mandatory. The manifest describes the module, and __init__.py imports its Python code. Odoo’s coding guidelines suggest a layout along these lines for anything bigger:
sale_delivery_window/
├── __init__.py
├── __manifest__.py
├── models/
│ ├── __init__.py
│ └── sale_order.py
├── report/
│ └── sale_order_templates.xml
├── static/
│ └── src/
├── tests/
│ ├── __init__.py
│ └── test_delivery_window.py
└── views/
└── sale_order_views.xmlThe same guidelines ask for one Python file per inherited model (sale_order.py for changes to sale.order) and a company prefix on community module names, so your stock_extra doesn’t collide with somebody else’s. There’s no security/ folder here because the addon only extends an existing model. The moment you add a new model, you need an access rights CSV for it.
How Odoo finds and loads one
At startup Odoo scans every directory on the addons path. A folder with a valid manifest shows up in Apps after you click Update Apps List in developer mode. Installing it, from Apps or with -i on the command line, installs everything in depends first. Then Odoo registers the addon’s models and loads its data files in the order the manifest lists them. Updating with -u runs that load again, which is how new fields reach the database and changed XML records overwrite the old ones, except those loaded with noupdate.
Dependencies behave like a package manager. Uninstall sale and every addon that depends on it is uninstalled too.
Keep changes out of core
The mess we clean up most often is edited files inside addons/sale itself. They work until the next Odoo update overwrites them. Everything a customization needs can come from a separate addon instead: _inherit for models (our post on _inherit vs _inherits covers the patterns) and XPath view inheritance for forms, lists and reports.
Size matters as well. One giant company_custom addon that touches sales, stock and HR can’t be installed or removed in parts, and its dependency list drags apps into databases that don’t use them. Several small addons with accurate depends age better.
When erpfly generates an addon for Odoo 17, 18 or 19 it follows that pattern: separate folders, inheritance instead of patches, delivered as a pull request. For a file-by-file walkthrough, see our guide to building a custom Odoo module.