When we first started implementing Odoo, there was a very tempting mindset: "If it's in the core, we’re going to use it.". That led us to activate every feature available: tasks, maintenance, email marketing, helpdesk, CRM… Since everything was integrated, it felt wrong not to use it.
But over time, we learned that the more apps you activate, the more complex the system becomes — and the harder it is for people to actually use it. This applies both to Odoo Enterprise and to Community + OCA setups.
The all-in-one trap
When you try to use everything the platform offers, you can run into issues like:
- You activate Marketing Automation because someone wants to send automated emails after quotations.
- You realise it doesn’t have Mailchimp-style templates, so everything has to be built manually.
- Then the salesperson complains that they can’t edit the email without breaking the flow.
- And finally, customers start receiving duplicate emails because the filters weren’t correctly set.
All of this happens because we overcomplicate things instead of starting with something simple — like a shared email template and a manual reminder.
The modules we end up removing
A common scenario: you start an implementation and install 20 modules at once. It may seem like a good idea, but six months later, you’ve disabled half of them. All of these modules can be powerful and useful — when they’re adapted to the actual workflow of the company. But when installed “just in case,” they only create noise.
Our experience tells us it’s better to start with the minimum number of modules, observe how people use the system, and then introduce new ones only when a clear and real need appears.
Hammers and nails
There’s also the risk of using modules in ways they weren’t designed for. It’s the classic case of “When all you have is a hammer, everything looks like a nail.”
We’ve seen companies get creative with the tools in order to avoid custom development. And while that can sometimes work in the short term, it usually means you end up forcing the system to do something it wasn’t built for.
Take internal task management for ISO implementation, for example. You could use the Projects module (which makes sense), or you could try to use the Maintenance module. But Maintenance is designed for tasks related to equipment, with very specific access rules. That leads to things like creating fake equipment, permission issues, and a constant sense that you’re “hacking” the system to fit a process that doesn't really belong there.
Conclusion
Odoo can do a lot. But that doesn’t mean you should use everything from day one.
Implementing less — but better — has given us more stable systems, happier users, and clearer processes. And in the end, that’s what we’re all aiming for.