Every Odoo project we’ve inherited from another vendor has the same problem: too much custom code, not enough configuration. Custom code looks like progress. Configuration looks like settings. Both deliver the same outcome — but only one survives the next Odoo upgrade.
The configuration-first rule
Before we write a line of Python, we run a single check: does Odoo already do this? Studio, automated actions, server actions, computed fields, the developer-mode toggles — these cover an embarrassing percentage of what most clients ask for. Configuration is invisible to upgrades. Custom code is not.
When configuration runs out
Some asks genuinely need code — a specific calculation, an external integration, a new screen. When we cross that line, we do two things: write the code in a separate module (never patch core), and keep it upgrade-safe by avoiding deprecated APIs and core overrides.
The 40% number
On the last three Odoo projects we ran, we tracked which client asks ended up as code and which as config. The split was almost 60/40 in favour of config — meaning nearly half the work we were quoting in days became settings changes that took hours. The client paid less, got the same outcome, and didn’t carry forward technical debt into the next upgrade cycle.
The trade-off
Configuration-first feels slower at the start because you spend time finding the right toggle. It’s faster overall because every upgrade after that costs you nothing. The math gets better every year.