Not every difference between a company process and an Odoo screen justifies a custom module. A field, access group, automated action, or a better operating rule may solve the problem without adding code. Other gaps are central to the business and deserve a model, workflow, and tests of their own.
The useful question is not whether the request can be programmed. Ask what operating problem it solves and what the smallest maintainable change looks like.
Use a decision ladder
Review the need in this order:
- Standard configuration when existing apps already have the required data and states.
- Odoo Studio for limited fields, views, and straightforward automation.
- External integration when another system must remain the source of truth.
- A custom module when the company needs a distinct data model, business rules, access logic, or user journey.
Each step adds ongoing cost. Custom code must be tested, documented, secured, and reviewed during every upgrade.
Strong signs that custom code is justified
A module is reasonable when the rule is central to the service, the data must be searchable and reportable, or permission depends on the individual record. It is also justified when a journey spans several Odoo apps with a company-specific stage between them.
Integrations need more than a single API call. Reliable code stores external identifiers, prevents duplicates, records failures, and supports safe retry. If a failure can change stock, money, eligibility, or access, automated tests should cover it.
Visual preferences alone rarely justify a business module. A theme, Studio change, or removal of the request may be cleaner.
Keep the module boundary narrow
Suppose a maintenance company receives a request, issues a quotation, reserves parts, records technician work, and asks the customer to approve before invoicing. CRM, Sales, Inventory, and Invoicing already cover much of that journey.
A custom service order might be useful for the asset, symptoms, inspection, technician time, parts used, approval history, and completion checks. It should connect to standard quotations and stock moves instead of rebuilding them.
The more standard behavior a module copies, the harder upgrades become.
Security belongs in the design
Model access and record rules before the interface feels finished. List who can read, create, edit, approve, cancel, and delete. Test ordinary users, managers, branch restrictions, and a user who should be denied.
Do not rely on hiding a menu or button. Server-side rules must reject unauthorized requests even when someone reaches a URL or calls a method directly.
Test behavior, not only installation
A module that installs successfully may still be unsafe. Tests should cover state transitions, calculations, duplicate protection, permissions, and upgrade-sensitive data.
For an integration, test timeouts, invalid responses, retries, and repeated delivery. For a financial or stock action, verify that a failed request does not create a partial result.
Price the lifetime of the module
The estimate should include analysis, implementation, tests, documentation, deployment, and the future upgrade path. The module also needs an owner for bug reports and version changes.
Custom development is valuable when it represents a real operating advantage or removes a serious risk. It becomes expensive clutter when it preserves an old habit that the standard workflow could replace.