Most requests that arrive as "we need this built" are not development requests. They are configuration requests wearing a development costume. Standard Odoo already covers a surprising amount of what teams assume is custom, and the difference between changing a setting and commissioning code is the difference between an afternoon and a project.
Getting that call right before anyone writes anything is one of the highest-leverage habits an ERP team can build. Here is how to make it deliberately instead of by instinct.
What configuration actually covers
Configuration is everything you can change through Odoo's own interface, without touching a module. That is a much wider surface than most new teams expect:
- Access rights, user groups, and record rules that decide who sees which records
- Document layouts, email templates, and the wording on quotations and invoices
- Pricelists, taxes, payment terms, and discount policies
- Warehouse routes, operation types, and multi-step receipts or deliveries
- Approval thresholds, double validation, and stage definitions on pipelines and projects
- Automation rules that trigger on a field change, a date, or a stage move
- Extra fields added through Odoo's own tooling and placed on existing forms and lists
If your requirement lands in that list, you do not need a developer. You need someone who knows where the setting lives.
What customization actually means
Customization is warranted when the behavior you want does not exist anywhere in the standard modules and cannot be assembled from them. In practice that means one of four things: a calculation Odoo does not perform, a document or process type Odoo does not have, an integration with a system that has no connector, or a decision you want the system to make rather than a step you want it to record.
Those are legitimate reasons to build. Industry-specific logic in particular tends to be real: a construction retention schedule, a rental billing cycle, a commission model that nobody else uses. That is the work our team handles as custom Odoo development, and it is worth doing properly when the requirement is genuine.
Four questions that usually settle it
Can you name the standard feature this replaces? If a standard module already does something close, you are almost always in configuration territory. The gap is usually 20% of the requirement, not 100%.
Is this about data or about behavior? Wanting to see a number that Odoo already stores is a report or a view. Wanting the system to act differently is code.
Would you accept the standard flow if someone explained it well? A meaningful share of customization requests are process preferences inherited from the previous system. They feel like requirements because the team has done it that way for years. They are not always worth carrying forward.
Does the requirement survive three rounds of "why"? Ask why the field is needed, why that value, why at that moment. Requirements that dissolve under three questions were solutions in disguise.
The cost you do not see on day one
Every customization is something you carry into every future version upgrade. Configuration mostly travels with you. Custom code has to be reviewed against each new release, tested, and occasionally rewritten when the underlying model changes. That is not an argument against customizing. It is an argument for customizing on purpose, with a clear idea of what the change buys you.
A good rule: if configuration gets you to 80% of the outcome, price the remaining 20% honestly, including its upgrade tail, before you commission it.
Where the ambiguous middle gets resolved
Plenty of requests sit in between. They are half process preference and half real gap, and nobody can tell which until the requirement is written down precisely.
That is the part Plemo is built around. Requests start as a conversation, and the platform asks clarifying questions instead of accepting the first phrasing. Over-broad requests get bounded rather than quietly expanded. Before development starts, you approve a written spec that says exactly what will be built, which is the last cheap moment to look at it and say "this is a setting, not a feature". And before anything reaches production, the change appears in a sandbox you can open and use.
None of that is a substitute for thinking. It is a structure that makes the thinking happen at the point where changing your mind is still free.
A practical order of operations
- Write the outcome, not the solution. "Finance needs to see committed spend per project" beats "add a field to the PO form".
- Search standard Odoo first, including modules you have not installed.
- If configuration gets you most of the way, decide whether the remainder justifies code and an upgrade obligation.
- If it does, write the spec, approve it deliberately, and review it in a sandbox before it goes live.
The teams who get the most out of Odoo are not the ones who customize least. They are the ones who can explain, for every customization they own, exactly why the standard system was not enough.