A requirements workshop for an ERP project typically produces forty to sixty "must have" items that standard Odoo does not do exactly the way the business currently does them.
The instinct is to customise all of them. That instinct is expensive.
The real cost of a customisation
The build cost is the part you see, and it is the smaller part.
The cost you do not see arrives at every future upgrade. Odoo ships a major version annually. Each one has to be tested against every customisation you hold. A module that took three days to build might take a day to re-test and fix each year, forever.
Twenty customisations turn an upgrade from a scheduled weekend into a project. That is why so many companies end up four versions behind, unsupported, and facing a migration that costs more than the original implementation.
The test we apply
For every requirement that does not fit standard Odoo, three questions:
1. Is this process a competitive advantage, or just a habit?
If the way you do it wins you business (a pricing model competitors cannot match, a quality process customers pay for), customise. If it is how it has always been done because the previous system worked that way, change the process.
Most requirements are habit. Saying so out loud is uncomfortable and saves a lot of money.
2. Is there a standard flow that gets 90% of the value?
Very often there is, and nobody has looked at it because the requirement was written before anyone saw the software. We show the standard flow, on the client's own migrated data, and ask whether the remaining 10% is worth a permanent upgrade tax.
Perhaps a third of the time the answer is no.
3. Can it live outside the core?
A report, a dashboard, an integration or a scheduled job sitting alongside Odoo carries far less upgrade risk than something that modifies core behaviour. If a requirement can be met adjacent to the system rather than inside it, that is almost always the cheaper long-term shape.
What usually survives
Of forty to sixty requirements, two or three justify deep customisation. Another handful become reports or integrations. The rest become process change plus training.
That ratio holds up remarkably well, and the projects that respect it are the ones still upgrading cleanly three years later.
How to have the conversation
The hardest part is not technical. It is telling a department head that the process they designed is not worth preserving in code.
What works: show the standard flow, on their data, and let them see it. Do not argue in the abstract. Half the time they will decide themselves that the standard way is fine, and a decision they reached is one they will defend to their own team.
The exception
Sometimes a requirement looks like habit, the client insists, and they are right: there is a regulatory or contractual reason nobody mentioned in the workshop.
That is why the test is a conversation, not a rule. We push back once, clearly, with the cost stated. If the answer is still yes, we build it properly and document why, so nobody in three years wonders what it was for.
