Skills
Odoo development means extending an ERP without breaking the consistency of its business model, permissions, and internal mechanisms. A module can add Python models, fields, XML views, QWeb reports, scheduled actions, API controllers, configuration data, and migration scripts. The difficulty is not merely making each component work: the ORM, inheritance, execution context, module dependencies, and framework conventions must be understood so a customization remains installable, testable, and compatible with future releases.
The skill also includes translating requirements. In an ERP, a technical rule often represents an accounting, sales, logistics, or security decision. I must identify reliable data, authorized users, exceptions, and effects on other applications. ACLs grant operations at model level, record rules restrict accessible records, and groups combine to define a user's privileges; hiding a screen is therefore never sufficient protection.
Finally, developing for Odoo requires choosing between standard behavior, configuration, Studio, and a version-controlled module. I favor standard functionality when it addresses the need, configuration when the rule should remain controlled by users, and code when behavior requires durable, reviewable, deployable logic. This boundary reduces technical debt and simplifies migrations.
The Odoo 19 release notes document cross-cutting changes to activities, customer documents, interfaces, and business applications. For an Odoo developer, each new release means understanding native capabilities before adapting existing modules and customizations.
Read the source: OdooI owned the successive migration from Odoo 16 to 17, 18, and then 19 for an ERP used by 20 direct internal users. The project included 16 custom modules, third-party extensions, and many Studio customizations. At each step, I adapted incompatible models, Python methods, XML views, and XPath expressions, researched changes in the source code, retrieved or fixed third-party modules, and checked PostgreSQL data and the filestore. Acceptance testing covered business processes, permissions, and external integrations, with a complete backup as the rollback point.
Result — Odoo 19 was deployed with no reported permanent data loss. Useful functions were retained, obsolete Studio customizations were removed, and the main integrations were modernized; downtime was not measured in a publishable way.
I developed and maintained sixteen modules that extend the ERP for accounting, sales, inventory, logistics, and sales administration. The overdue-reminder module illustrates the complete approach: requirement gathering, decision matrix, settings, Python models, XML views, permissions, scheduled action, email templates, attached report, staging tests, business validation, Odoo.sh deployment, and training. Other modules enrich products, QWeb reports, invoice margins, or logistics documents. I select only the directories and components required by the need instead of mechanically reproducing a full structure.
Result — These modules automate daily tasks, make documents more complete, and provide management indicators during the financial year. The reminder module notably automates invoice checks and reminder stages; its time savings remain to be measured.
The B2B website and integration hub depend on customers, products, stock, and orders stored in Odoo. I created focused API routes when standard mechanisms did not satisfy the exchange contract and helped adapt integrations to Odoo 19's JSON-2 API. To prevent an interface solution from exposing data, I reason separately about ACLs, groups, record rules, and sensitive fields. When behavior appears inconsistent, I read logs, trace method inheritance, and inspect source code rather than accumulating workarounds in views.
Result — External systems resumed their main data exchanges after the migration, and internal modules remain controlled in the versioned repository. This ability to work down into the framework lets me correct a defect's cause rather than only its display.
Current Odoo task workflow in Jira
Captured on September 17, 2026. The board organizes Odoo requests by status, from analysis through review and deployment readiness. It illustrates my current daily workflow, not the migration project's historical backlog.
The evidence items describe specific episodes. This synthesis places them back in the complete case studies: context, my contribution, and outcome show what this skill made possible, while keeping the appropriate level of caution for each result.
I assess myself as advanced. I can design, migrate, secure, deploy, and maintain modules spanning several departments, and I can investigate behavior in the source code. I do not consider myself an expert: the accounting engine, deep ORM optimization, and some internal interactions remain areas where I need more measurement before making changes.
This is the most important technical skill in my current profile. It combines Python, PostgreSQL, XML, APIs, security, deployment, and understanding of business processes. It also matches my objective of becoming a senior developer and Odoo technical specialist.
I learned Odoo from scratch during work-study while quickly becoming the only in-house developer responsible for requests. Modules, incidents, and migrations accelerated my progress beyond a purely theoretical path, but that speed also explains some early implementations that relied too heavily on fixed values.
My advice is to start with the business process and standard features before writing a module. Configuration and algorithm should then be separated, tests run with representative accounts and data, and source code inspected as soon as actual behavior contradicts the hypothesis. Studio is useful for a lightweight change, but version-controlled code is preferable when logic is critical or durable.
Build on my advanced proficiency so I can define the architecture of a module suite, prepare migrations in advance, and guide other developers on security, performance, and maintainability decisions.
