Why Do People Say Odoo Is Bad? The Real Complaints, Examined

Search for opinions on Odoo and you will find both enthusiasm and genuine frustration, often about the same features. Rather than dismiss the criticism, it is more useful to take each complaint seriously and ask a single question of it: is this a property of the software, or a property of how it was deployed?

Here are the six that come up most, assessed honestly. Some of them are fair.

Why does Odoo get criticised?

Because Odoo is flexible, cheap to start with, and sold through a large partner network — three qualities that make it very easy to deploy badly. A system that can be configured any way will be configured badly by someone, and a low entry price attracts projects that were never resourced properly. The resulting experience is real, and the user quite reasonably attributes it to the software.

Complaint 1: it is slow

This is the most common and the least often about Odoo. In the performance reviews we have been called into, the cause has been one of four things nearly every time: a server sized for a pilot and never resized, default worker configuration, a PostgreSQL that has never been tuned or vacuumed, or a custom module computing something expensive on every write.

Verdict: usually not the software. It is a real experience with an infrastructure cause, and it is fixable — typically faster and more cheaply than anyone expects.

Complaint 2: the free version is a trap

The argument goes that Community is offered free, then you discover you need Enterprise modules and the cost arrives anyway.

There is something in this, but “trap” is unfair. The edition split is published and the module list is public. What actually happens is that nobody checks it carefully before starting, discovers mid-project that a needed feature is Enterprise-only, and experiences a planned commercial boundary as an ambush.

Verdict: partly fair, entirely avoidable. Confirm which edition covers your specific requirements in writing before the project starts.

Complaint 3: upgrades break everything

The fairest complaint on the list. Odoo ships a major version annually, and custom modules written against internal behaviour rather than stable extension points do break.

But note what is being described: the upgrade exposes fragile customisation. An instance with little custom code upgrades uneventfully. An instance with a large pile of poorly written overrides is expensive to move, and would be in any system.

Verdict: fair, and it is an argument for restraint in customisation rather than against Odoo. The companies that find upgrades routine are the ones that configured where they could and coded only where they had to.

Complaint 4: you need a developer for everything

Mostly untrue, and it is often a symptom of who was hired rather than what the software requires. A great deal of Odoo is configuration: fields, views, workflows, approval rules, reports, automated actions. A functional consultant can do this without writing code.

Where this complaint becomes true is when a development-led partner answers every requirement with a module. It is a faster answer to give and a far more expensive one to own.

Verdict: usually a partner problem. Ask any prospective partner to show you the last three requirements they met with configuration instead of code.

Complaint 5: the accounting is not serious enough

This one depends heavily on country and on what the finance team is used to. Odoo Accounting handles invoicing, reconciliation, multi-currency, tax and standard financial reporting well for small and mid-sized businesses, and localisations exist for many jurisdictions.

Where the criticism lands is in deep statutory reporting in specific countries, or in finance teams expecting the analytical depth of a tier-one system to be present by default. Both are addressable, but they are configuration and localisation work, not an out-of-the-box expectation.

Verdict: context-dependent. Have your accountant test your actual statutory reports during evaluation, not after go-live.

Complaint 6: partner quality is inconsistent

True, and it is the structural weakness of any large partner ecosystem. The same software delivered by two firms produces two completely different experiences, and the buyer usually cannot tell which they have bought until months in.

Verdict: fair, and it is the single most important risk a buyer can control. Ask for references in your own industry, ask to see a written scope from a real past project, and treat a partner who says yes to everything as a warning rather than a convenience.

What the complaints have in common

Five of the six describe decisions made around the software rather than the software itself: how it was hosted, how it was scoped, how much code was written, who delivered it. The sixth — upgrades — is a genuine characteristic of annual-release software, and it is managed by keeping customisation disciplined.

That is not a defence of Odoo so much as an observation about ERP generally. The same complaints, in almost the same words, are made about every system in this market. What varies is how recoverable they are, and Odoo's openness makes most of them unusually recoverable: you can inspect the database, read the source, and move if you need to.

If you are evaluating Odoo right now

Take the six complaints above and turn each into a question for whoever is selling to you. Who sizes and monitors the hosting? Which of my requirements need Enterprise? How much custom code will this scope need, and who owns upgrading it? What will configuration cover? Will my accountant's statutory reports work on day one? Can I speak to a client in my industry?

A partner who answers those six precisely is the difference between the good Odoo story and the bad one. The software is the same in both.

Frequently asked questions

Is Odoo actually bad?

No. It is a mature, widely deployed ERP with an unusually broad module range for its price. Most published criticism describes a badly hosted, badly scoped or badly maintained deployment rather than a flaw in the product, which is why the same software gets opposite reviews from different companies.

Why do some Odoo projects fail then?

For the same reasons ERP projects fail generally: undefined processes, no internal owner, scope that grows without a decision, dirty data migrated as-is, and training treated as an afterthought. The software choice is rarely in the top five causes.

Is Odoo slow by design?

No. Performance complaints almost always trace to under-provisioned hosting, default worker settings left untouched, an untuned PostgreSQL, or custom code doing heavy work on every record write. A correctly sized and configured instance is responsive.

Do Odoo upgrades really break customisations?

They can, and this is the fairest complaint on the list. Custom modules written against internal behaviour rather than stable extension points are the ones that break. Keeping customisation minimal and well written is what makes annual upgrades routine instead of frightening.

How do I avoid the bad experience?

Size the hosting properly, keep customisation small, stay on a supported version, migrate clean data, name an internal owner, and choose a partner who will tell you when the answer is no. Those six decisions separate almost every good Odoo story from every bad one.