— Odoo / Customization

Odoo, customized properly. Or not at all.

Custom Python modules, Studio configuration and code remediation — written by an in-house Python team, delivered as Git repositories under your namespace, designed to survive every Odoo upgrade we have done since version 14.


In one paragraph

In-house Python team. Not subcontracted. Every line of code reviewed by a senior before merge.

Upgrade-safe by design. Customers who started on Odoo 14 are still running our modules on Odoo 18.

You own the Git repository. Every module documented and version-controlled under your namespace.

We push back on customizations. Roughly half of inbound customization requests turn into configurations or process changes.

What it includes

Inside a customization engagement.

We treat each customization as a discrete deliverable with its own scope, price and acceptance test. The bundle below is the full menu — most engagements use a subset.

01

Custom Python modules

Net-new Odoo modules written from the data model up — for vertical workflows, regulated calculations, or business rules stock Odoo cannot express.

02

Studio configuration

No-code customization for fields, simple forms, reports and basic automation that your super-users should be able to own.

03

Custom reports and dashboards

QWeb PDF reports, Excel exports, OWL dashboards. Branded, bilingual, with the data your finance and ops actually need.

04

Workflow and approvals

Multi-stage approvals, segregation of duties, escalation paths and audit trails enforced at the ORM layer.

05

Code audits and remediation

Take-over of poorly built customizations from previous partners. Audit, plan, refactor — module by module, with a written report.

06

Upgrade migrations

Bringing custom modules across Odoo major versions (16 → 17 → 18). Done as a discrete phase, not a surprise during a routine upgrade.

07

Custom views and UX

OWL component work, custom field widgets, kanban tweaks and form-view changes that make the system feel native to your team.

08

Documentation and handover

Every module ships with a README, architecture diagram, and an acceptance-test list. You — or another partner — can pick up the work cold.

Process

Spec, build, prove, ship.

Customization fails when the spec is loose. We write it down before any code is written, and we do not deviate without a documented variation.

  1. Phase 01

    Discovery

    Walk the use case. Verify there is no stock Odoo or configuration path. Document the exact business rule. Sign off the spec.

  2. Phase 02

    Design

    Data model, ORM impact, UI changes, automated test plan. Reviewed before any code is written.

  3. Phase 03

    Build

    Python module written against the spec, ORM-clean, with no monkey-patching of core. Versioned in Git from commit one.

  4. Phase 04

    UAT

    You run the acceptance test cases on a staging instance with your data. We fix defects inside the fixed fee.

  5. Phase 05

    Deploy

    Module installed on production, smoke-tested, monitored. Documentation handed over with the Git repository.

  6. Phase 06

    Support

    Customizations are covered by AMC like any other part of the system. Bug fixes during the warranty window are free.

Who this is for

Operators with real edge cases.

UAE and GCC businesses already running Odoo (or about to) who have a handful of genuinely unique business rules that stock modules cannot express — and who want those rules built properly rather than bolted on.

Three patterns we see most often. The first: a manufacturer with a costing model — landed cost, contract pricing, scrap-recovery — that does not match Odoo's standard valuation flows. The second: a regulated business — healthcare, financial services, government supplier — that needs auditable approval workflows, segregation of duties, or industry-specific reports baked in. The third: a partner-takeover scenario where another shop shipped fragile customizations and the system can no longer be upgraded.

Bad fit: customizations driven by reluctance to change a process, or "we have always done it this way" arguments. We will challenge that in Discovery.

Pricing approach

Per-customization fixed-fee.

Every customization is scoped, priced and dated as a discrete deliverable. We do not run customization on T&M because it removes the discipline that makes customizations small and ship-able.

For multi-customization engagements we bundle related items into a fixed-fee phase — typically 4 to 8 weeks of build and UAT — with one acceptance milestone at the end. Acceptance is binary: either the customization meets the spec or we keep working inside the original fee.

For ongoing customization work after go-live we offer a customization retainer — a monthly hour bank with a senior developer assigned to your account, used against a prioritized backlog. This is the right model for businesses that have a steady stream of small-to-medium customization needs.

What success looks like

Two upgrades later, still running.

A customization is successful when, two Odoo major versions later, it is still in production, still maintained, and the business has forgotten it is a customization at all.

That is the standard we build to. See case studies for specific customization stories — including a few partner-takeover remediations where we brought failing systems back to upgradeable.

FAQ

Customization questions, answered.

When should we customize Odoo and when should we not? +

Customize when standard Odoo cannot represent a real business rule that is genuinely unique to your operation — multi-stage approval flows, regulated industry workflows, vertical-specific calculations. Do not customize because someone is uncomfortable changing a habit, or because your previous system did it a different way. We push back on every customization request: can we configure it instead, can we change the process instead, or is this genuinely necessary code? Roughly half the customization requests we receive end up not being customizations after that conversation.

What does "upgrade-safe" actually mean? +

It means the code we write does not monkey-patch Odoo core, does not override critical methods without calling super(), uses ORM APIs rather than raw SQL, declares its dependencies cleanly, and lives in its own Git repository under your namespace. The result: when you upgrade Odoo 17 to 18 to 19, your customizations come along with you instead of needing to be rebuilt from scratch. We have customers who first engaged us on Odoo 14 and are now on Odoo 18 with the same custom modules still running.

Studio vs custom Python — which is better? +

Different tools for different jobs. Studio (Enterprise-only) is great for adding fields, building simple forms, customizing reports and creating lightweight automation — work your own super-users can own. Custom Python is necessary for real business logic, integrations, complex calculations and anything that needs to be tested or version-controlled properly. Most engagements use both: Studio for the simple 80%, Python modules for the 20% that genuinely needs engineering.

Do we own the code? +

Yes. Every custom module we write for you is delivered as a Git repository in your namespace, with full documentation. You can take it to another partner. You can hire your own developers to extend it. There is no escrow, no proprietary wrapper, no consultant lock-in. We sell our work, not our hostages.

Can you fix code another partner wrote badly? +

Yes, and we do this often. Roughly a quarter of our customization engagements are remediation — taking over Odoo systems where the previous partner shipped fragile or undocumented customizations. We start with a paid code audit, produce a written remediation plan, then refactor module by module. We will not paper over technical debt. If a module needs a rewrite we will say so.

How do you scope and price customization work? +

Each customization is a discrete deliverable with its own scope, price and acceptance test. We bundle related customizations into a fixed-fee phase rather than open-ended T&M. Acceptance is binary: either the customization meets the spec we wrote together or it does not. If it does not, we keep working on it inside the original fee until it does.

— Ready when you are

Talk to a real ERP consultant.

A 30-minute call is the fastest way to know if we're a fit. No slides.