Custom Odoo development is the right answer when a process is specific to your business and standard Odoo, configuration or a maintained community module cannot cover it. I build such modules and integrations myself, as separate add-ons that extend Odoo instead of patching it, with automated tests and a documented release step. The code lives in your repository and stays readable for whoever maintains it next.
When is custom code the right answer?
Before writing code I check three cheaper options: can standard Odoo do it with different settings, can an existing maintained module from the Odoo Community Association do it, and can the process itself change. Custom code is justified when the answer to all three is no and the process brings real value. Every custom module is a long-term cost: it has to be tested, maintained and ported at every upgrade.
What kind of modules do I build?
Examples from recent client and own work, described without client names:
Manufacturing
A shop-floor terminal where operators log in with a PIN; an importer that turns a CAD file list from SolidWorks into products and multi-level bills of materials; drawing and assembly-instruction links on products and bills of materials.
Subcontracting and stock
Automatic creation of a dedicated stock location per subcontractor, and a check that the required components are physically at the subcontractor before a receipt is validated, scaled correctly for partial deliveries.
Valuation and accounting
Stock valuation for foreign-currency purchases that stays tied to the order and invoice date, with automatic reconciliation of interim accounts and clear errors for edits that would distort valuation.
Services and portals
Service agreements and statements of work across several companies and currencies, monthly timesheets and expenses entered and approved in the customer portal, and self-billing for external consultants.
Access control
A module that manages model access and record rules through reviewed policies with a publishing step and an audit history, and explains where each user's rights come from. Tested on Odoo 16, 17, 18 and 19.
Audit trail
A tamper-evident audit log with a hash chain, login events with IP addresses, a retention period and export for archiving. Tested on Odoo 17, 18 and 19.
How do integrations work?
Most integrations use Odoo's External API with a dedicated technical user and its own API key, so the integration has exactly the rights it needs and can be revoked without touching people's accounts. For inbound data, such as webhooks from another system, I build controllers that validate a signature or token. Public URLs never expose records by sequential ID: that pattern lets anyone read other customers' documents by changing a number in the address.
What code quality standards do I follow?
| Standard | What it means in practice |
|---|---|
| No core patches | All changes are separate modules using model, view and template inheritance |
| Automated tests | Tests run on install with Odoo's test framework, including a user who belongs to one company only and at least two languages |
| Tested on a copy | Every install and update is run first on a copy of your database, never directly on production |
| Security review | Access rules, record rules and public routes are checked for data leaking between companies or users |
| Upgrade-safe | Standard methods are extended with super() rather than replaced, and version-specific changes are documented |
| Translations | User-facing texts are translatable and shipped with translation files for the languages you use |
| Versioned releases | Each change raises the module version and is recorded in a changelog |
These standards come from real problems: an invoice line that stayed in English on a localised invoice because a third-party report module replaced a translated block with fixed text, and multi-company rules that look correct until they are tested with a user who belongs to a single company.
Who owns the code?
You own what you pay for. Modules are delivered to your git repository, with their history, tests, a short technical README and a user note for the key users. Nothing depends on my servers or my accounts. If a module includes my previously built components, the licence terms are agreed in writing before the work starts.
How does delivery work?
Scope and acceptance test
A short written description of what the module does and how your key user will verify it.
Build and test
Development with automated tests, then installation on a copy of your database with real data.
Acceptance
Your key user tests on the copy. Findings are fixed until the acceptance test passes.
Release
Backup, update on production, a quick check of the affected flows, and the changelog entry.
Tell me about your Odoo
Describe your situation in a few lines. We reply by e-mail.
Frequently asked questions
Who owns the code you write?
You do. The modules are delivered into your git repository with their history, tests and documentation, and you can let any other developer or partner continue the work. Licensing is agreed in writing before the work starts, so there are no surprises later.
Do you modify Odoo core files?
No. Changes are made in separate modules that extend standard models and views through Odoo's inheritance mechanisms. Patching core files breaks with the next update and makes upgrades expensive, so it is excluded by design.
Can you take over modules written by another developer?
Yes. I start with a code review: what the module does, which core methods it replaces, whether it has tests and whether it works on the target version. Then we decide whether to fix, rewrite or replace it with standard functionality.
How are changes deployed to our production system?
Through your repository and a documented release step: backup, update of the module on production, quick checks of the affected flows. For self-hosted systems I give your admin exact commands; on Odoo.sh the release follows its branch workflow.