When to customise Odoo and when to keep the standard flow

Odoo customisation is justified when it protects a valuable requirement that configuration and reasonable process change cannot meet sustainably.

Custom code is not inherently bad, but it creates an asset the business must test and maintain. The decision should compare business value with delivery risk, user impact, and the cost of future upgrades. Identify the protected outcome Write the reason behind the request. A legal control, contractual rule, competitive workflow, high-volume efficiency gain, or necessary integration may justify development. Familiarity with an old screen usually does not. Test alternatives in order Review standard configuration, user roles, reports, automated actions, process adjustment, and supported applications. Demonstrate the alternative with realistic data rather than rejecting it from a feature list. Estimate lifetime cost Include analysis, development, security, tests, documentation, user training, support, and upgrade work. A small override in a core flow may cost more over time than a larger isolated module. Keep the scope narrow Implement the smallest coherent rule that meets the requirement. Avoid copying entire views or methods when an extension point, configuration record, or focused model can achieve the result. Practical checklist State the business, legal, or control outcome being protected. Demonstrate standard and configuration alternatives first. Estimate testing, support, and upgrade cost, not only build time. Prefer isolated extensions over broad core overrides. Assign a business owner and measurable acceptance test. Final decision Customise when the value survives honest comparison with simpler options. If nobody can explain the outcome or own the maintenance, the request is not ready for development.