Services

Odoo Customisation & Development

Standard Odoo covers a remarkable amount, and the first honest answer in any customisation conversation is whether you need custom code at all. When you genuinely do (a workflow that is your competitive edge, an industry rule standard Odoo doesn’t model), customisation done well makes Odoo fit like it was written for you.

We’ve been writing Odoo modules for 11 years across versions 8 to 19. That includes knowing what not to build, because we’ve maintained other people’s overbuilt systems through painful upgrades.

What the work involves

  • Framework-native development. Custom modules built the way Odoo’s own are: proper models, inherited views, ORM discipline, access rights. No core hacks, ever, because core hacks die at every upgrade.
  • Upgrade-survivable design. Every customisation is written knowing versions 20 and 21 are coming. We’ve ported our own manufacturing accounting work across four major versions; that experience shapes how we structure code today.
  • Side-effect awareness. Odoo modules interact. Our review process specifically hunts the second-order effects (a stock rule change breaking dropship flows, a partner constraint breaking POS) that cause production surprises.
  • Staging-first delivery. Custom work lands on staging with your real data, gets tested against defined acceptance criteria, and only then promotes to production.
  • Documented handover. You get technical documentation and clear ownership of the code. No hostage situations.

How custom work is delivered

  1. Specification from the business outcome. We start from what the work must achieve, not a feature list, and write it down so both sides can point at it later.
  2. Fixed quote with an hours breakdown. You see where the effort goes before committing. Vague briefs get discovery questions, not padded numbers.
  3. Build on staging against acceptance criteria. Development happens against your real data structures, with the acceptance tests agreed upfront.
  4. Your sign-off on staging. You test the work where breaking things is free. Nothing promotes to production on our say-so alone.
  5. Deploy, document, hand over. Production release, technical documentation, and the code in your repository. No hostage situations.

Common questions

How do you price custom development?
Scoped fixed prices for defined features with an hours breakdown you can challenge; time-and-materials only for genuinely exploratory work, with weekly transparency.
Will customisations break when we upgrade?
They'll need porting; that's the honest answer everyone should give you. The variable is porting cost, which good architecture keeps small. We build for that day and can show you modules we've carried across four versions.
Can you take over custom code another partner wrote?
Yes, we start with a code audit that tells you what's solid, what's fragile and what's dangerous, then we agree what to stabilise before adding anything new.
How do we know a customisation is worth it versus changing our process?
We'll tell you the configuration-only answer first, with its trade-offs. Custom code has to beat process change on total cost including future upgrade portage, and we put that comparison in the proposal.
What happens to our customisations if we stop working with you?
Nothing bad: the code is in your repository, documented, written in standard Odoo patterns any competent partner can maintain. We compete on being good, not on lock-in.

Not sure where to start? Book a free discovery call and we’ll map your current setup, or request a free Odoo health check if you’re already running Odoo.

Next step

Ready to fix your ops?

Book a free discovery call. We'll look at your current setup and tell you honestly whether Odoo is the right move and what it would involve.