The "Yes-Man" Problem in ERP
Here's a dirty secret about the ERP industry: many partners make more money saying "yes" to every customization request than saying "no." Custom development bills at premium rates. Ongoing maintenance creates recurring revenue. And when migrations break, someone has to fix them—for a fee.
I've spent 15 years implementing Odoo, and I've seen this pattern destroy businesses. A company starts with "just a few tweaks," then adds "one more module," then builds "a small integration." Five years later, they're trapped: unable to upgrade, paying €30,000/year to maintain code that replicates features Odoo added to the standard product three versions ago.
Odoo can be coded to do almost anything. The question is: should it? This article is my case for the "Standard-First" philosophy—and a warning about the quicksand of unlimited customization.
The 'Perfect Fit' Myth
"We need Odoo to work exactly like our current system." I hear this in almost every initial consultation. And it's almost always the wrong goal.
Think about what you're actually asking: you want to take a modern, battle-tested ERP used by 12+ million users and force it to replicate the workflows of your legacy software—software you're replacing because it no longer serves you.
Odoo's standard workflows aren't arbitrary. They're the distillation of thousands of implementations, refined over 15+ years. They encode best practices for inventory management, accounting compliance, sales pipelines, and manufacturing operations. When you customize around them, you're not just building code—you're rejecting accumulated wisdom.
The metaphor I use: Imagine buying a new house designed by an award-winning architect, then immediately tearing out walls to recreate the layout of your old apartment. You've destroyed the design integrity, created structural problems, and you'll pay for it every time you want to renovate.
Before approving any customization, ask: "Is this process actually better than Odoo's standard, or are we just comfortable with it?" Comfort is not a business case.
What is Technical Debt? (Plain English)
Technical debt is the future cost of shortcuts taken today. In Odoo terms: every custom module you build is a loan against your future self. And the interest rate is brutal.
Here's what happens when Odoo releases a new version (v18 → v19 → v20):
- Standard databases: Migration is largely automated. Odoo provides official upgrade scripts. Most companies migrate in 2-4 weeks with minimal consulting support.
- Customized databases: Every custom module must be analyzed, refactored, and tested against the new version. Migration scripts must be written manually. Dependencies break. Conflicts emerge. A "simple" upgrade becomes a 3-6 month project.
The numbers are stark: heavily customized databases cost 5x more to migrate and take 3x longer. I've seen companies skip three major Odoo versions because they couldn't afford the migration—then face an even larger bill when they finally had to move.
Custom modules often store data in non-standard ways. When Odoo's data model changes (and it does, every version), you need custom "migration scripts" to transform your data. Writing and testing these scripts can cost $5,000-$15,000 per major module.
Odoo's internal APIs evolve. Methods get deprecated, renamed, or restructured. Custom code that "hooks" into Odoo's core will break. Every. Single. Upgrade.
The cruelest irony: features you paid to build often appear in standard Odoo 2-3 versions later. Now you're maintaining legacy code that competes with native functionality.
If you suspect your Odoo instance is carrying technical debt, a structured Odoo Audit can quantify it—before your next upgrade turns into a six-figure surprise.
The 80/20 Rule of Odoo
My philosophy: 80% Standard, 20% Configuration. Notice I said configuration, not customization. These are fundamentally different:
Using Odoo's built-in tools to adapt behavior: Odoo Studio for UI tweaks and simple fields, Automated Actions for workflow triggers, Server Actions for business logic, Reporting modifications, and Settings/Parameters. Configuration travels cleanly between versions.
Writing new Python modules, overriding core Odoo methods, creating custom data models, or building external integrations. Customization creates permanent maintenance obligations.
The goal: Exhaust every configuration option before considering customization. Odoo Studio can handle 80% of "we need this field" requests. Automated Actions can replace 70% of "when X happens, do Y" requests. Only when these tools genuinely can't solve the problem should you reach for custom code.
Before any custom development, require your partner to document: (1) Why Studio/Automated Actions can't solve this, and (2) The estimated migration cost for the next 3 Odoo versions. If they can't answer, they haven't done their homework.
When Customization IS Necessary
I'm not an absolutist. There are legitimate reasons to build custom code. But they're rarer than most companies think:
If a process is genuinely your "secret sauce"—the thing that differentiates you from competitors—it may warrant custom development. But be honest: is your three-step approval workflow really a competitive advantage, or just organizational habit?
Some industries have genuinely unique requirements: specialized pricing algorithms, regulatory compliance calculations, or domain-specific quality control protocols. If Odoo doesn't serve your vertical, custom code may be unavoidable.
Connecting Odoo to proprietary manufacturing equipment, specialized barcode systems, or industry-specific IoT devices often requires custom connectors. These are legitimate technical necessities.
The test: If you removed this customization, would you lose customers or market position? If the answer is no, you probably don't need it.
The Question That Changes Everything
Here's the challenge I give every client before we discuss customization:
"Is your current process actually better than Odoo's standard workflow, or are you just used to it?"
This is uncomfortable. It forces people to justify habits they've never questioned. But it's the difference between implementing an ERP that transforms your business and building an expensive replica of your existing dysfunction.
I've watched warehouse managers insist on custom picking workflows, only to discover that Odoo's standard wave picking reduced their labor costs by 20%. I've seen accountants demand custom approval chains, then realize that Odoo's standard three-way matching caught errors their manual process missed for years.
The "process pivot" isn't about forcing you into a box. It's about earning the right to customize. Prove that your way is genuinely superior, with data, before asking for code.
Our Commitment to Your Future
This is what we promise every client:
"We will always tell you 'No' if a customization will hurt your future upgrades—even if it means we bill fewer development hours today. We will challenge your assumptions, protect your migration path, and recommend standard Odoo features over custom code whenever possible. Your long-term success is worth more than our short-term revenue."
This isn't marketing. It's survival. Our reputation depends on clients who are still happily using Odoo five years from now—not on clients trapped in unmaintainable systems blaming us for their pain.
Cost of Migration: Standard vs. Customized
Here's the 5-year reality for a 30-user company, assuming one major Odoo upgrade every 2 years:
| Cost Category | Standard Database (Configuration only) | Heavily Customized (15+ custom modules) |
|---|---|---|
| Initial Implementation | $25,000 | $55,000 |
| Migration 1 (Year 2) | $4,000 | $22,000 |
| Migration 2 (Year 4) | $4,500 | $28,000 |
| Annual Maintenance | $3,000/year ($15,000 total) | $12,000/year ($60,000 total) |
| Bug Fixes & Patches | $2,000 total | $18,000 total |
| 5-YEAR TOTAL | $50,500 | $183,000 |
| Cost Multiplier | 1x (baseline) | 3.6x |
The customized database costs $132,500 more over 5 years. That's not including the business disruption of longer migrations, the opportunity cost of delayed features, or the eventual "rip and replace" when the technical debt becomes insurmountable.