/services/odoo-customisation
Custom code, only where standard can't reach.
Custom modules, workflow automation and UI changes — written against the standard-first test, delivered into your repository, and documented so somebody else could maintain them.
- 3 questions every request has to pass
- 100% custom code delivered to your repository
- 180+ projects behind the judgement
Facts. - 3 · questions every request has to pass - 100% · custom code delivered to your repository - 180+ · projects behind the judgement
/the-problem
Every line of custom code is a maintenance cost.
Custom code is not free at the point of writing and it is never free afterwards. It has to survive every version upgrade, be understood by whoever comes next, and be re-tested whenever the module underneath it changes. A feature that took three days to build can cost that much again at each upgrade for as long as the system lives.
Which would be a fine trade if every customisation earned it. Most don't. A large share of requests we receive are a standard module used slightly differently, a report that already exists under another name, or a process that was designed around a limitation in the system being replaced — and nobody has revisited whether the limitation still exists.
So every request goes through the same three questions before anyone opens an editor. Does the standard module already do this? Can configuration get there? Is the process itself the thing that should change? Only what survives all three gets written.
/what-well-talk-you-out-of
What we'll talk you out of
- Custom modules where a genuine capability gap exists
- Workflow automation across modules that don't natively talk
- Reports and dashboards beyond what the standard engine reaches
- UI changes where the standard screen genuinely obstructs the work
- Third-party integrations with proper error handling and retry
- Data model extensions for information Odoo has nowhere to hold
- Migration of custom modules across version upgrades
- Rebuilding a standard screen because it looks unfamiliar
- Automating a process that should be simplified instead
- Replicating a workaround from the system you're replacing
- Custom reporting that Studio or a pivot view already covers
- Hard-coding a rule that changes twice a year
- Anything a configuration setting reaches, however inelegantly
/how-we-run-it
Six stages. Most requests stop at stage two, on purpose.
Applies whether the request arrives during an implementation, through an AMC, or as standalone development work on a system somebody else built.
-
01
Requirement
What the user is actually trying to do — not the solution they've arrived at. These differ more often than not.
0.5–1 day
-
02
Standard-first test
The three questions. If configuration or a process change reaches it, we say so and stop here.
0.5–1 day
-
03
Technical design
Approach, data model changes, upgrade implications. Written down before it's built.
1–3 days
-
04
Build
Developed in your repository, on a branch, against the design.
varies
-
05
Test & review
Functional testing against the requirement, code review against the design, upgrade path checked.
1–2 days
-
06
Handover
Merged with documentation and a README. Recorded in your change log.
0.5 day
/what-you-get
Four artefacts you keep.
Custom code is the part of an ERP most likely to become undocumented and unmaintainable. These exist to make that harder.
The standard-first decision
what was requested, what was built, and why the alternatives were rejected. Including the requests we declined.
/02Technical design
approach and data model changes, written before the build.
/03The code, in your repository
commented, on a branch, with its own README. Never only in ours.
/04Upgrade note
what this module touches and what to re-test at the next version.
/where-this-fits
What comes before this, and what comes after.
Customisation is never the first conversation. Consulting and implementation establish what standard Odoo reaches; customisation covers what's genuinely left; support maintains it and carries it through upgrades.
/questions
Asked on every first call.
-
It can, and that's the cost we're managing. Anything we write carries an upgrade note listing what it touches and what to re-test, and version compatibility is reviewed ahead of every upgrade under an AMC. The way to keep upgrades cheap isn't better custom code — it's less of it.
-
Possibly, but not before running the standard-first test on it. A meaningful proportion of quoted customisations turn out to be configuration, a standard feature under a different name, or a process worth changing. If yours survives the test we'll build it and say why it was necessary.
-
You do. It's delivered into your repository, commented, with a README. If you replace us, nothing about your system becomes unknowable — that's a deliberate constraint on how we work, not a courtesy.
-
Yes, after an audit. We won't take on maintenance for code we haven't read, and occasionally the audit says the honest answer is a rewrite rather than a patch. You'll hear that before you commit, not during.
-
It's scoped per requirement after the standard-first test, because the test frequently changes what's being built. Small changes on an existing system usually come out of drawdown hours under an AMC or a Success Pack rather than a separate quote.
/next
Send us the requirement, not the specification.
Thirty minutes, no slides. We will tell you straight if Odoo is not the answer.