Odoo Customization
Custom code is a liability you agree to carry. We keep it small, keep it in its own module, and write it so the next upgrade does not eat it.
Custom modules, workflows, reports, and OWL components engineered so Odoo fits your business, not the other way around.
Most customisation requests are one of three things: a real difference in how your business works, a report nobody could find, or a habit carried over from the last system. Only the first is worth code. Part of this service is telling you which of the three you have, before anyone is billed for building it.
When code is the right answer, the way it is written decides what it costs you over the next five years. Everything goes in its own module, never as edits to Odoo core or to a third-party app. Behaviour is added by extending existing models rather than replacing them, so a version upgrade has something to attach to. The parts that hold money or stock get tests, because those are the places where a silent regression is expensive.
You get the source. It is your code, in your repository, with a readable commit history and a handover session. No obfuscation, no licence key that stops working when the relationship ends, and no dependency on us to make the next change.
What is included
- โ Custom Python modules and business logic
- โ Workflow automation with server actions
- โ Custom reports (QWeb, XLSX, PDF)
- โ OWL component development
- โ Industry-specific workflows
- โ UX and branding customization
- โ Automated tests (pytest, tours)
- โ Code review and handover
How the engagement runs
- 1
Requirement capture
Understand the business rule, not the screen someone imagined.
- Work backwards from the outcome: what should be true after the action, and who checks it
- Find where the rule already half-exists in standard behaviour
- Establish the edge cases now: returns, cancellations, partial quantities, multi-company, multi-currency
- Agree who is allowed to override the rule, because there is always someone
You end up with: A written requirement with the edge cases listed and the override rules stated.
- 2
Technical specification and estimate
Decide the smallest change that satisfies the requirement.
- Choose the extension point: field, computed value, constraint, automated action, or new model
- Decide what is configuration data and what is code, so the client can change the first without us
- Write the acceptance criteria as statements that can be tested
- Estimate per item, so items can be cut individually rather than the whole request being deferred
You end up with: A specification with acceptance criteria and a per-item estimate.
- 3
Build in sprints
Working code in front of you every week, not a long silence and a launch.
- One module per coherent feature, with its own manifest and dependency list
- Extend, do not overwrite. Core files are never edited
- Access rights and record rules written at the same time as the model, not after a security review
- Automated tests on the logic that touches money, stock or approvals
- A demo on a staging database at the end of each sprint
You end up with: Reviewable code on a staging instance, sprint by sprint.
- 4
Test and review
Prove it holds up against your data and your permissions.
- Your team tests against the acceptance criteria, using their own logins and their own restrictions
- Performance checked against realistic record counts, not against ten demo rows
- Upgrade impact noted for anything that touches a heavily customised area
- Code review before anything reaches the live database
You end up with: A signed test pass and a reviewed changeset.
- 5
Deploy and hand over
Move it to live safely and leave you able to maintain it.
- Deploy through staging first, with a rollback plan and a database backup taken immediately before
- Release notes written for users, not for developers
- Repository access, branch conventions and build instructions handed to your side
- A walkthrough of the code with your developer if you have one
You end up with: Live code, tagged release, source in your repository, and written handover.
What you need to provide
The schedule slips on these more often than on anything technical.
- โ A person who can describe the rule and has authority to confirm the edge cases
- โ Access to a staging database that mirrors live, including realistic data volume
- โ Sample records that break the rule, not just the ones that fit it
- โ Existing custom modules and their source, if the instance already carries any
- โ The exact document layouts you expect, where the work involves printed output
- โ Testers with the same access rights as the eventual users
- โ A decision on which Odoo version the work targets, if an upgrade is planned
Decisions you will be asked to make
Configure, customise, or change the process
Configuration is free to change later. Code is not. We show you the standard behaviour first and ask you to explain why it fails, and a fair share of requests stop at that point without anyone losing anything.
Build it, or buy something that already exists
If a maintained module already covers most of the requirement, buying it is cheaper than building and keeps you off a private fork. We say so even where it means less work for us.
How much of it should be settings
Anything a manager might reasonably want to change should be a setting, not a constant in code. Settings cost a little more up front and save a support ticket every time the number moves.
How far to take testing
Tests are worth it on anything that posts to the ledger, moves stock or bypasses an approval. On a colour change they are not. We agree the line rather than applying a blanket rule.
Where this goes wrong
The failure modes we plan around, and what the plan does about each one.
Requirements captured as screenshots
A picture of the intended screen hides the rule behind it, and the rule is the thing that has to survive an upgrade. We write the requirement as behaviour first, and the interface follows from it.
Core files edited directly
It works until the first update, then it silently reverts or breaks the module that depends on it. Everything goes in a separate module that extends rather than replaces.
Access rights left until the end
Custom models added without record rules are visible to everyone, which is usually discovered by the wrong person. Rights are written with the model.
Performance tested on demo data
Logic that is fine on ten records can be unusable on a hundred thousand. Anything that loops over records or computes across a table is checked at real volume before it ships.
One giant module
Bundling unrelated features into a single module means you cannot uninstall one without losing the others, and an upgrade fails as a whole rather than in one place. One module per coherent feature.
No handover
Code you cannot read is code you have to keep paying the original author to touch. Source, repository access and a walkthrough are part of finishing, not an extra.
Not included
Stated up front so the proposal has no soft edges.
- ร Changes to Odoo core, which we will not make on any instance we support
- ร Reverse-engineering or patching an encrypted third-party module without its author's licence
- ร Maintaining custom code written by someone else, without a paid review first
- ร Free rework of a requirement that changed after sign-off: it is quoted as a change request
- ร Guaranteed upgrade compatibility for code we did not write
- ร Graphic design and brand assets: we implement what your designer supplies
How this is priced
Customisation is quoted per item so the list can be trimmed rather than postponed as a block. Small well-specified pieces run fixed-price. A moving backlog runs on time and materials with a monthly ceiling you set.
See the published bands โModules that come up on this work
Ready-built modules from our own catalogue. Where one of these covers the requirement, installing it beats writing it.
Dashboard Builder - Drag & Drop KPI Dashboards
Build live KPI dashboards on any Odoo model - numbers, bar charts, ranked lists & progress, with drag-and-drop tiles.
Why here: A large share of customisation requests are really reporting requests. A configurable dashboard closes many of them with no code at all.
ProductivityGantt View for Odoo 19 Community
Gantt planning board with a real scheduling engine: dependencies, automatic rescheduling, critical path, resource conflicts and a printable planning sheet.
Why here: Scheduling views are one of the most common gaps requested on Community, and building one from scratch is rarely worth it.
ProjectGrid View for Timesheets and Resource Planning
Spreadsheet style grid for any model: rows are records, columns are days, weeks or months, cells are editable totals written straight back to the database.
Why here: Spreadsheet-style entry is a frequent request from teams migrating off Excel, and an existing view saves a bespoke build.
ProductivityMap View for Odoo 19 Community
Put any model on a map, geocode addresses once and cache them, and plan a visiting route with distances, for Odoo Community.
Why here: Field-service and route requests usually start as a map. Cheaper to install than to write.
ProductivityWT Custom Backend Theme
Customizable backend theme - color presets, side menu, fully responsive, Odoo 19 Community
Why here: Branding requests are better served by a configurable theme than by hand-edited stylesheets that break at the next upgrade.
Theme/BackendOdoo Debranding / White Label
White-label Odoo completely - replace the Odoo name, logo, favicon and "Powered by Odoo" everywhere with your own brand, driven from the Company form.
Why here: White-labelling comes up on almost every client-facing deployment, and doing it by hand leaves traces in places nobody remembers to check.
ToolsCustom modules, Odoo Studio work where Studio is enough, and the Odoo API where a screen is not the right answer.
Where we deliver this
Custom work often has a local reason behind it. The country pages set out what is already handled without code.
Odoo Customization: common questions
Will customisation break our next Odoo upgrade?
Well-written custom modules do not break, they need porting, and the effort depends on how deeply they reach into standard behaviour. Code that extends existing models ports quickly. Code that replaces standard logic is expensive at every version. That is the single biggest reason we push back on requests that duplicate what Odoo already does.
Do we own the code?
Yes. Source goes to your repository with the commit history intact, plus build and deploy instructions. There is no licence key, no time bomb and no obfuscation. If you replace us, the next team can read what we wrote.
Can you work on custom modules another vendor built?
Usually, after a paid review. We need to see what state the code is in before promising anything, because inherited modules occasionally turn out to be core edits in disguise, and that changes the answer completely.
How do you keep customisation from growing forever?
Every request has to survive one question: what breaks in the business if the standard behaviour is used instead. Requests that cannot answer it go on a parked list. Teams that review that list a quarter later usually delete most of it.
Do you write tests?
On logic that touches money, stock, approvals or anything customer-facing, yes. On cosmetic work, no, because the test costs more than the defect. We agree the line during specification rather than applying one rule to everything.
What is a realistic turnaround for a small change?
A single well-specified field or report is usually a matter of days including review and deployment, and the review and deployment are most of it. The delay on small changes is almost always waiting for a decision, not waiting for code.
Read next
Odoo Implementation
End-to-end Odoo deployment, from discovery to go-live.
Hire Odoo Developer
Dedicated developers by the week or month.
Odoo Integration
Connect Odoo with your stack and third-party APIs.
Odoo Migration & Upgrade
Upgrade safely from older Odoo versions.
Odoo Health Audit
Deep technical + functional audit of your instance.
Tell us what you are trying to fix
A 30-minute call is usually enough to tell you whether this is a small piece of work or a project, and to say so before anyone writes a proposal.