Odoo Customization · intermediate · 12 min read
How to Estimate Odoo Custom Development
Estimate Odoo customization work realistically: discovery, unknowns in existing code, fixed price vs time-and-materials, risk buffers, and what estimates must include beyond coding.
Last reviewed 2026-07-30 · Estimated effort: 2–6 weeks typical implementation slice
Table of contents
Good Odoo estimates start with discovery: which standard apps are in play, what already exists in custom addons, and which business rules are still ambiguous. Coding hours alone are not an estimate.
Existing custom code is the largest unknown. Brittle xpath, undocumented overrides, and missing tests can turn a “small field” into a multi-day refactor. Budget explicit time to read the codebase—or choose time-and-materials until the fog clears.
Decide fixed price versus T&M based on how stable the scope is. Every serious estimate should include UAT support, documentation, deployment, security work, and a risk buffer—not just model and view development.
Buyers ask for a number; experienced Odoo teams ask for constraints. Estimation is the process of making those constraints visible: scope, quality bar, unknowns, and commercial model.
This article is for managers and technical leads who need estimates they can defend—whether building in-house or buying from a partner. It focuses on customization work (modules, views, security, integrations touchpoints), not full greenfield ERP rollouts.
Spend structured time clarifying the business outcome, the Odoo apps involved (`sale`, `stock`, `mrp`, `account`, …), user roles, and edge cases. Capture configuration options that might remove the need for code. Write acceptance criteria in plain language.
Technical discovery lists installed custom modules, Studio leftovers, server environment, and target Odoo version. Without that inventory, you are estimating fiction.
- ▸Outcome and success metrics
- ▸Standard vs custom touchpoints
- ▸Roles and permissions impacted
- ▸Data volume and performance sensitivity
- ▸Go-live constraints and freeze windows
When the database already has years of customization, open the risky modules before committing to a fixed fee. Look for core edits, monkey-patches, wide method overrides, and views with fragile xpath. Each finding either expands the estimate or becomes an explicit exclusion.
If access to the codebase is delayed, estimate a discovery spike separately, then re-estimate build work. Do not pretend a black-box system is a clean Community install.
Fixed price fits well-bounded changes with clear acceptance tests and a cooperative UAT owner—e.g. a new report, a validated field set, a small wizard. Change requests need a written process or the fixed price becomes a fiction.
T&M (or a capped T&M) fits exploration, rescue work, heavy legacy refactoring, and programmes where priorities shift weekly. Pair T&M with a visible backlog, weekly demos, and a burn report so finance stays comfortable.
- ▸Fixed: stable scope + known codebase + clear UAT
- ▸T&M: discovery-heavy, rescue, or evolving backlog
- ▸Hybrid: paid discovery → fixed build for a slice
Add buffer for integration ambiguity, data cleanup, and multi-company surprises—typically a visible contingency line, not a hidden pad on every task. Call out assumptions: “Assumes no core edits in sale module,” “Assumes staging restore available within 48 hours.”
Line items that must appear: analysis, implementation, automated or manual tests, security (ACL/record rules), documentation, UAT support rounds, deployment (including backup/rollback), and short hypercare. Estimates that only show “dev days” understate cost and train buyers to expect unfinished work.
Present ranges or phased options when uncertainty is high: MVP path, recommended path, and stretch path. Tie each option to business value and upgrade risk. Revisit the estimate when discovery findings invalidate assumptions—silence is what creates distrust later.
- ✓Fund a short discovery or code audit before locking a fixed price on legacy systems.
- ✓List assumptions and exclusions next to every commercial number.
- ✓Include UAT, docs, security, deploy, and hypercare as explicit estimate lines.
- ✓Use T&M or a hybrid when acceptance criteria are still moving.
- ✓Size buffer from measured risks (unknown modules, integrations), not a flat 10% habit.
- ✓Re-estimate after the first working vertical slice if the codebase surprises you.
- ✓Agree who pays for waiting time (late UAT feedback, missing credentials, frozen environments).
- !Estimating from a feature wish list without opening the existing custom addons.
- !Quoting only coding hours and forgetting UAT loops and deployment.
- !Accepting fixed price while the business still debates the process.
- !Hiding contingency so every overrun looks like failure.
- !Ignoring multi-company, localization, or accounting side effects.
- !Assuming Studio customizations are “free to replace” in code.
- !Skipping hypercare and being surprised by week-one production tickets.
Honest Odoo estimates separate what is known, what must be discovered, and what the commercial model can absorb. Discovery, legacy risk, and non-coding delivery work belong in the number.
If a quote looks simple, ask what it excluded. The exclusions—not the hourly rate—usually decide whether the project finishes cleanly.
| Option | Best when | Trade-off |
|---|---|---|
| Configure | Standard Odoo covers the need | Limited uniqueness |
| Customize | Differentiating workflow | Upgrade cost |
| Integrate | External system of record | Sync complexity |
- Owners named
- UAT scripts signed
- Rollback documented
- Hypercare roster ready
Frequently asked questions
How long should discovery take?
For a single bounded customization, a few hours to two days may be enough. For a crowded legacy database, a one- or two-week audit with a written findings note is cheaper than a wrong fixed bid. Stop discovery when assumptions are testable—not when every edge case is solved.
Why do partner quotes differ so widely?
They often price different scopes: some exclude UAT and training, some assume clean core, some include refactor of dangerous code. Compare line items and assumptions, not only the bottom line. The cheapest quote that ignores security and upgrades is usually the most expensive upgrade later.
Can we estimate in story points instead of days?
Yes for internal agile teams, but convert to calendar capacity when talking to finance and go-live dates. Odoo work still needs explicit allowance for staging restores, `-u` testing, and business UAT that does not fit neatly in points.
What if the business wants a fixed price tomorrow?
Offer a paid discovery with a fixed fee and a delivery estimate as the output—or a fixed price only for a narrowly written MVP with explicit exclusions. Saying yes to an unbounded fixed price is how rescue projects are born.
Related articles
When Should You Customize Odoo?
Decision criteria for customizing Odoo: when to change the process instead, when Studio is enough, and when a custom module is justified.
View →Odoo Customization Best Practices
Operational best practices for sustainable Odoo customization: staging, code review, ACL and record rules, documentation, definition of done, small PRs, and post-deploy monitoring.
View →Common Odoo Customization Mistakes
Frequent Odoo customization failures: editing core, monkey-patches, missing security, no staging, undocumented changes, and over-customizing reports—plus how to avoid them.
View →How to Maintain a Customized Odoo System
Keep customized Odoo healthy over years: clear ownership, dependency inventory, regression testing, support retainers, upgrade readiness, and knowledge transfer.
View →Need a scoped estimate or a discovery spike?
We provide discovery-led estimates for customization work and audit-first rescue when an existing quote no longer matches the codebase.
