Short answer: A good Odoo project estimate spells out scope, phases, deliverables, acceptance criteria and a change process, and ties payments to results. An open-ended "we bill until the hours run out" estimate leaves your budget without control. Deep Vision, an Odoo Gold Partner in Tashkent, runs a diagnostic first and then prepares a phased estimate.
Before starting an Odoo project, most business owners ask one question: "How much will it cost?" The more important question is: "How will the budget be controlled?" This article walks through how an Odoo project estimate should be structured, which payment model is safer, and how to avoid the trap of endless billable hours.
What is an Odoo project estimate and what should it contain?
An Odoo project estimate is a document that ties together scope, phases, deliverables, timelines and cost; it is not just a price but a description of what exactly you are paying for.
An honest estimate contains at least:
- Scope: which processes (sales, inventory, purchasing, accounting, manufacturing) and modules are included, and which are explicitly excluded.
- Phases: the outcome of each phase, for example "Sales and Inventory live, staff trained".
- Work types: analysis, configuration, data migration, integrations, custom development, training, post-go-live support.
- Assumptions: what the estimate relies on, such as number of users, data formats and how fast the client makes decisions.
- Acceptance criteria: when a phase counts as finished.
- Change process: how a new requirement is assessed and approved.
- Risks: which factors could affect cost or timeline.
If the estimate just says "Odoo implementation: X", you are not buying an outcome. You are buying uncertainty.
Fixed scope or time and materials: which is safer?
Fixed scope means an agreed price for an agreed outcome; time and materials means paying for the hours actually spent.
Both models have their place:
- Fixed scope works well for clearly defined phases: you know the result and the provider is accountable for efficiency. The risk: if the scope is vague, the provider either builds in a large buffer or bills separately for every small change.
- Time and materials suits uncertain or exploratory work, such as a complex integration. The risk: without a ceiling, the hours never end and the budget becomes open-ended.
In practice, the most balanced approach is a mix: the diagnostic and core phases on a fixed scope, and the uncertain parts on hours with a hard cap. What matters is not the model's name but its boundaries: whichever model you pick, scope, outcomes, decision-making and monthly reporting should be agreed in writing.
Where does the "endless hours" risk come from?
Typical reasons budgets grow under an open hourly model:
- processes nobody analysed get "discovered" during go-live;
- every wish is solved with code and brings new hours;
- there is no single decision-maker, so the same question is debated again and again;
- there are no acceptance criteria, so a phase never formally closes.
A longer timeline is also money. According to McKinsey and Oxford research, every additional year of project duration adds 15% to cost overruns, and large IT projects run 45% over budget on average. Gartner expects that more than 70% of recently implemented ERP initiatives will not fully meet their original business goals by 2027. Budget discipline is not red tape; it is a condition for results.
How should change requests be managed?
A change request is a written process for assessing and approving any new requirement that falls outside the agreed scope.
New ideas during a project are normal. The problem is not the ideas themselves but adding them without control. A good process works like this:
- the new requirement is logged, along with who asked for it;
- the provider estimates its cost, its effect on the timeline and a standard alternative;
- the responsible manager decides: "now", "next phase" or "not needed";
- approved changes are kept in a separate log, so the budget is always visible.
Often the wisest answer is "next phase": the system goes live, people start using it, and a month later half of the requests turn out to be unnecessary.
How do you structure milestone payments that are fair to both sides?
Milestone payments link each payment to an accepted deliverable rather than to a calendar date.
As the client, look for the following:
- each payment is linked to the outcome of a specific phase;
- a phase is closed with a sign-off or the results of acceptance testing;
- part of the final payment is made after a stabilisation period;
- licences and hosting are shown separately from service fees;
- the contract states that custom code and documentation will be handed over to you.
This structure protects the provider too: they get paid on time for each phase, and you pay only for results you have received.
Self-check list for any Odoo estimate
- Does it state clearly what is out of scope?
- Does every phase have a deliverable and an acceptance criterion?
- Are standard configuration and custom development shown separately?
- Is the data migration scope clear (which data, how many years)?
- Are training hours and materials listed?
- Is a change request process described?
- Is there a cap on any hourly components?
- Are payments tied to deliverables?
- Are the duration and cost of post-go-live support stated?
- Are the project consultants named, along with their Odoo certifications?
For general pricing, see Odoo ERP pricing in Uzbekistan. For the overall project stages, see our Odoo ERP implementation guide.
How Deep Vision builds an estimate
Deep Vision is an official Odoo Gold Partner. Our page on odoo.com lists 7 certified experts, 20+ references and 89% customer retention. The Gold tier requires 300 new Enterprise users a year, which means a large, steady volume of delivered projects.
How we work:
- Diagnostic first: we study your processes, data and goals, so the estimate is based on facts rather than guesses.
- Then a phased estimate: each phase shows its own deliverable, timeline and cost.
- Fast first results: standard Sales and Inventory are often live in 6–8 weeks, and a full project typically takes 2–6 months.
- Less custom code: we start with standard Odoo and our ready-made modules for Didox and Asl Belgisi.
For example, at Timsoll, an auto parts business with 18 branches and more than 7,000 SKUs, setting up a new product in the system went from 6–8 months to 2–3 days: the Timsoll case. Our team includes experienced specialists who know industries and finance, so our estimates are tied to business outcomes. To book a diagnostic, send us a brief or read about our Odoo implementation service.
Frequently asked questions
Can you give an exact price without a diagnostic?
Only a rough range. An accurate estimate comes after studying processes and data; otherwise the price either carries a large buffer or grows later.
Is a fixed-price contract always better?
When the scope is clear, yes. When it is vague, a fixed price usually includes a buffer or grows through change requests.
What should we do if a new requirement appears mid-project?
Raise it as a written change request, assess its effect on cost and timeline, and decide: now, in the next phase, or not at all.
Should we keep a contingency in the budget?
Many companies set aside a separate contingency for unforeseen work and spend it only on approved changes. Its size depends on how uncertain the project is.
Who should control the budget?
One accountable manager on the client side and a project manager on the provider side. At the end of each phase they compare planned and actual costs.
Sources
- McKinsey: delivering large-scale IT projects on time, on budget and on value
- Gartner: ERP initiatives and expected outcomes
- Odoo partner tiers
- Deep Vision — Odoo partner page
Want a transparent estimate for your project? Send us a brief or call +998 77 093 00 07.