Odoo Studio vs Custom Development: When to Use Which?

60-70% of ERP projects experience significant challenges. The cause is almost always organizational, not technical: over-customization, accumulated technical debt, and custom modules that become blockers with every major update. Before writing a single line of Python, here's the decision framework we apply to every project.

The 80/20 Rule: Standard First, Always

Odoo covers 80% of business needs out of the box. The first question to ask isn't 'How do we build this?' but 'Doesn't the standard already handle this?' Many 'specific requirements' disappear once users see the standard workflow in action. The philosophy: 80% standard, 20% configuration — and that's configuration, not customization.

Level 1: Odoo Studio (Zero Code)

Studio handles roughly 80% of 'we need this field' requests. Use it for:

• ✓Adding custom fields to any model (text, selection, computed)
• ✓Modifying list, form, and kanban views without touching XML
• ✓Creating custom PDF reports
• ✓Adding tabs to customer records, opportunities, or sales orders
• ✓Configuring custom pipelines and stages
• ✓These changes migrate cleanly between versions — zero maintenance cost

Level 2: Automated Actions (Zero Code)

Automated Actions replace roughly 70% of 'when X happens, do Y' requests. In Settings → Technical → Automated Actions, you can trigger actions on:

• ✓Record creation or modification (trigger: record creation/update)
• ✓A specific field change (e.g., stage_id moves to 'Won')
• ✓Time-based conditions (e.g., follow up if a quote is unsigned after 7 days)
• ✓Available actions: send an email, update a field, call a webhook, create a linked record
• ✓Combine multiple conditions with Python-like domain filters

Level 3: Custom Python Modules (Last Resort)

Only when Studio and Automated Actions genuinely cannot solve the need. The non-negotiable rules for a maintainable custom module:

• ✓Always a separate module with its own manifest.py — never modify core files
• ✓Use _inherit on existing models rather than creating from scratch unless necessary
• ✓Use only the Odoo ORM (models.Model, fields, api decorators) — no raw SQL unless performance-justified
• ✓Reference records by XML ID (module_name.record_id), never by integer ID (they change between environments)
• ✓Document the module: why it exists, which models it inherits, non-obvious decisions
• ✓Before coding: document why Studio/Automated Actions are insufficient

The Real Cost of Over-Customization

• ✓Standard migration (little/no customization): 2-4 weeks, scripted automatically by Odoo
• ✓Migration with heavy custom modules: 3-6 months, manual scripts, $5,000-$15,000 per complex module
• ✓Every customization = hidden cost at each major version (Odoo releases one per year)
• ✓The AppStore (4,000+ modules) migrates automatically — search there before coding

Checklist Before Any Custom Development

• ✓1. Does a native setting already solve this?
• ✓2. Can Studio add the missing field or view?
• ✓3. Can an Automated Action automate this workflow?
• ✓4. Does an AppStore module already exist?
• ✓5. If custom dev: is the module separate, _inherit used, XML IDs everywhere?
• ✓6. Has the v+1 migration cost been estimated and documented?

Over-customization is the primary long-term failure factor in Odoo projects. A well-configured standard ERP will always be more performant, cheaper to maintain, and easier to evolve than one overloaded with custom modules.