Start with the business outcome
Ask what control, record, decision or report the business actually needs. Recreating a legacy screen because users are familiar with it is not automatically a valid requirement.
Use standard behavior where it is genuinely suitable
Standard functionality usually carries the lowest upgrade and maintenance burden. That does not mean forcing the business into a poor fit; it means understanding what the platform already does before replacing it.
Treat customization as an owned product decision
Every customization should have a business owner, testable requirement, upgrade impact and support expectation. A custom module becomes part of the operating system and must be maintained accordingly.
Know when deep engineering is justified
Complex approvals, specialized industry workflows, localization, integration or statutory needs may require deeper work. The correct goal is not “zero customization”; it is controlled customization with clear value.
Use a five-step decision ladder
Start with the business outcome, then test the requirement in this order: standard behavior, configuration, report or workflow design, integration, and finally custom code. The order matters because each step usually adds more ownership and upgrade responsibility than the previous one.
Skipping directly to code can reproduce an old process without asking whether the process itself should survive. Equally, forcing a genuine operating requirement into unsuitable standard behavior creates user workarounds. The decision should minimize unnecessary engineering without denying legitimate complexity.
Run an upgrade-debt test before approving custom code
Ask who owns the requirement, which data model it changes, which permissions it introduces, what external dependencies it has, how it will be tested, and what happens at the next Odoo upgrade. If those questions cannot be answered, the organization is approving technical debt without naming it.
A good customization request should be possible to describe as an acceptance scenario: given these records and permissions, when this user performs this action, this result and evidence must exist. That makes future regression testing far more dependable than relying on a screenshot of the original implementation.