Short answer: An Odoo team that promises "we will build whatever you ask" feels convenient at first, but every wish becomes custom code, upgrades break and costs grow year after year. Good Odoo requirements describe business goals rather than a wish list, and check the standard solution first for every requirement. Deep Vision starts projects in exactly that order: diagnostics, standard features, then only justified code.
When choosing an Odoo partner, many managers look for the most flexible team: "we will adapt to your processes and build everything the way you are used to". The promise is attractive, because nobody likes changing habits. But if the Odoo requirements document (often called a technical specification) is built the wrong way, that flexibility becomes the most expensive mistake in the project. Here is why the order-taker approach is risky, how to spot it, and what to demand instead.
What is the "we will build whatever you ask" approach?
The order-taker approach is a way of working in which the provider accepts every client request without analysis and turns it straight into configuration or code. Such a team asks no questions, does not push back, and never says "this is already standard" or "you do not need this". It acts as an order desk.
On the surface this looks like respect for the client. In reality nobody asks the questions that matter: which problem does this requirement solve, can a ready Odoo feature cover it, and who will maintain this code two years from now?
Why should Odoo requirements not be a wish list?
In many companies the specification is born like this: each department head writes down their wishes, someone merges them into one file and sends it to the provider. The document ends up with 150 items, many of which copy screens from the old software and Excel sheets.
Such a list hides three problems:
- Requirements contradict each other (sales wants freedom to give discounts, finance wants strict control).
- Many items describe how a screen should look, not how a process should work.
- No item is linked to a business outcome: there is no "why do we need this" column.
A good specification is built differently. First come goals (for example, "cut order picking time", "see receivables daily"), then processes, and only then screens and reports. Every requirement is tagged: standard, configuration or custom code.
What happens when every wish becomes code?
The consequences of the order-taker approach usually show up not in year one but in years two and three:
- Upgrades break. Odoo releases a new version every year. Each custom module has to be migrated and re-tested. The more modules, the more expensive and risky the upgrade.
- Costs grow. Code is written once, but it has to be maintained every year.
- Chaos gets automated. If a process is wrong, copying it exactly into software only makes the errors faster.
- You get locked in. A system full of non-standard code is hard to hand over to another team.
A McKinsey and University of Oxford study of more than 5,400 IT projects found that large IT projects run 45% over budget on average and deliver 56% less value than predicted; each additional year of duration adds 15% to cost overruns (McKinsey). Uncontrolled requirements push a project down exactly that path.
What do the Gartner numbers say?
Gartner predicts that more than 70% of recently implemented ERP initiatives will fail to fully meet their original business goals by 2027 (Gartner). A Gartner analyst quoted by The Register put it this way: 70% fail to fully meet business case goals, and 25% fail catastrophically (The Register).
These numbers are not about bad technology; they are about project management. An ERP project is not a software installation but a change in business processes. If the partner never proposes changing a process and only moves the old one onto new screens, the result stays the same as before.
What does good advice look like?
A qualified Odoo partner sometimes says "no" and explains why. For example:
- "There is no need to build this report: the standard Odoo pivot report with grouping gives you the same data."
- "A three-step approval in the warehouse can be coded, but standard routes and access rights cover it and will not cause trouble at upgrade time."
- "This requirement really is your competitive edge, so we will build it as a separate module and document it."
Note that a good advisor is not against everything. They do not refuse to write code; they turn it into a deliberate decision. On choosing between an off-the-shelf system and building from scratch: Build an ERP from scratch or use a ready system.
How to check your provider: a buyer's self-check
After the proposal and the first meetings, answer these questions:
- Did the provider say about at least one of your requirements "this is standard, no code needed"?
- Does the proposal include a separate analysis or diagnostics phase?
- Is every requirement in the specification tagged "standard / configuration / code"?
- Are the volume of custom code and the cost of upgrading it stated?
- Did the provider suggest changing a process, or only promise to copy the old one?
- Is there an agreed procedure for change requests?
- Is the provider listed in the odoo.com partner directory, with client references shown?
If the answer to the first two questions is "no", you may be talking to an order-taker. The full list of questions: How to choose an Odoo partner in Uzbekistan.
How does Deep Vision handle Odoo requirements?
Deep Vision is an official Odoo Gold Partner based in Tashkent. Our odoo.com page shows 7 certified experts, 20+ client references and an 89% customer retention rate (partner page). Whether clients stay with a partner usually depends on how the system works in the years after go-live.
Our sequence:
- Diagnostics: interviews with the owner and each department, goals written down.
- Requirements map: every requirement is tagged standard, configuration or code and agreed with the client.
- Ready-made solutions: we have modules for Didox and Asl Belgisi, so those integrations are not rebuilt from scratch every time.
- Phased rollout: standard Sales and Inventory often go live in 6–8 weeks; a full project typically takes 2–6 months.
Our team includes experienced specialists who know industries and finance, so when we say "no", we can explain why. On pricing structure: Odoo ERP pricing in Uzbekistan. Service details: Odoo implementation.
If you would like us to review your specification, fill in the brief.
Frequently asked questions
Our processes are unique. Won't standard Odoo fall short?
Some processes really are unique. In practice, though, most requirements are covered by standard modules and configuration. Code is worth writing only for what remains.
Should we write the specification ourselves?
You state goals and problems; the document itself should be written together with the partner's consultant. A ready-made list does not replace the analysis phase.
If a provider says "no", does that mean they do not want the work?
If the "no" comes with an alternative solution, it is professional advice. An unexplained refusal is a different matter.
Is more custom code always worse?
It is not about volume but justification. Every module needs a reason, documentation and an upgrade plan.
What if a new requirement appears mid-project?
That is normal. What matters is that it is logged as a change request and its effect on cost and timeline is estimated.
Sources
- Deep Vision, odoo.com partner page
- Gartner: ERP initiatives and expected outcomes
- The Register: Gartner analyst on ERP failures
- McKinsey: delivering large-scale IT projects on time, on budget and on value
Start your requirements with goals, not wishes: fill in the brief or call +998 77 093 00 07.