It is a scenario every agency owner dreads.
Six weeks ago, you had a great first introductory call with a client. They asked for a rough idea of cost, and you gave them a quick ballpark estimate of “$50,000 to $70,000.”
Today, after doing a deep dive into their requirements, you present the final, detailed proposal. The price is $95,000.
The client is furious. “You lied to us! You said $50k! This is bait and switch!”
You didn’t lie. You didn’t bait and switch. But you did fail to manage expectations about how software pricing evolves.
The root cause of this conflict is a fundamental concept in software engineering called the Cone of Uncertainty.
If you don’t understand this concept, you will constantly over-promise and under-deliver. If you do understand it, you can turn angry clients into educated partners who understand the reality of building complex systems.
This guide will explain exactly why early estimates are always wrong, define the three professional stages of estimation, and give you the scripts to explain it to clients.
Table of Contents
- What is the Cone of Uncertainty?
- Why clients hate ambiguity (and how to fix it)
- Stage 1: The ROM Estimate (Rough Order of Magnitude)
- Stage 2: The Budgetary Estimate
- Stage 3: The Definitive Estimate
- Client Scripts: How to explain pricing evolution
- The danger of skipping Discovery
- How devtimate helps manage uncertainty
- Checklist
- FAQ
What is the Cone of Uncertainty?
The “Cone of Uncertainty” is a visual model used in project management that describes the evolution of the amount of uncertainty during a project.
In simple terms: At the beginning of a project, you know almost nothing. Therefore, your estimate will have a massive margin of error.
As you move through the project, gathering requirements, designing screens, investigating APIs - you learn more. As your knowledge increases, uncertainty decreases, and your estimates become more accurate.
The Weather Analogy: Think of it like forecasting the weather.
- If you ask a meteorologist, “Will it rain on this specific day next year?”, their guess is useless. The uncertainty is too high.
- If you ask, “Will it rain next week?”, they can give you a decent probability (e.g., “60% chance”).
- If you ask, “Will it rain in one hour?”, they can look at the radar and give you a nearly precise answer.
Software is the same.
The Math of the Cone: According to industry studies on software engineering economics:
- At the very start (Initial Concept), an estimate can be off by a factor of 4x (+/- 400%).
- After requirements gathering, it narrows to roughly +/- 50%.
- Only after detailed technical design does it narrow to +/- 10%.
The problem is that clients want +/- 10% accuracy on Day 1, when the reality is +/- 400%.
Why clients hate ambiguity (and how to fix it)
Clients are not evil for wanting a fixed price early. They have bosses, boards, and budgets to report to. They need certainty to get approval.
When an agency says, “It depends, we don’t know yet,” the client hears incompetence.
The mistake agencies make is pretending they have certainty when they don’t. They give a single number ($50,000) early in the cone just to please the client. The client anchors to that number, and when reality hits later, trust is destroyed.
The Fix: Stop giving “estimates” and start giving “ranges based on project stages.”
A professional agency never gives just one type of estimate. They use different names for different levels of accuracy as they move through the cone.
There are three standard professional stages you must adopt.
Stage 1: The ROM Estimate (Rough Order of Magnitude)
- When: The very first sales call or email exchange.
- Input Data: A 1-page brief, a verbal description of an idea, or a napkin sketch.
- Accuracy: Very Low (+/- 50% to 100%).
- Purpose: To check if the client has a viable budget. To see if they are looking for a Honda or a Ferrari.
A Rough Order of Magnitude (ROM), often called a ballpark estimate, is not a quote. It is a categorization tool.
It should always be presented as a very wide range. For example: “$40,000 to $80,000.”
Never spend more than an hour creating a ROM. Use historical data or AI estimation tools to generate it quickly. Its only job is to determine if it’s worth having a second meeting.
- Read more on how to create these quickly in our guide on creating ballpark estimates in under 30 minutes.
Stage 2: The Budgetary Estimate
- When: After a few meetings, perhaps after reviewing some initial wireframes or a feature list.
- Input Data: A high-level feature list or a basic requirements document.
- Accuracy: Medium (+/- 20% to 30%).
- Purpose: To secure initial funding approval from stakeholders for the next phase.
A Budgetary Estimate is more refined than a ROM. You have identified the major “monster features” (like complex integrations) and have a general sense of the scope.
The range narrows. The previous $40k-$80k ROM might now become a Budgetary Estimate of “$60,000 to $75,000.”
This is often the estimate used to sign a contract for a Paid Discovery Phase. It is still not a fixed price for development.
Stage 3: The Definitive Estimate
- When: Only after a completed Discovery Phase and technical design.
- Input Data: A completed Work Breakdown Structure (WBS), finalized UI/UX designs, API documentation review, and a defined technology stack.
- Accuracy: High (+/- 5% to 10%).
- Purpose: To sign a fixed-price development contract or set a very tight budget for an Agile project.
A Definitive Estimate is the gold standard. It is bottom-up, meaning every single small task has been identified and estimated individually.
You have moved to the narrow end of the Cone of Uncertainty. You have eliminated the unknowns.
The previous $60k-$75k Budgetary Estimate might now become a definitive quote of “$72,500.”
Crucial Rule: You cannot give a Definitive Estimate without doing the deep engineering work first. If you try to skip straight to this stage, you are just guessing with confidence, which is dangerous.
Client Scripts: How to explain pricing evolution
You need to teach your clients this concept without sounding academic. Use these scripts to manage expectations when they push for a fixed price too early.
Script 1: The Weather Analogy (For the first call)
*“I can give you a number right now, but I want to be honest with you: it would be like trying to predict the exact temperature on this day next year. There are too many unknowns.
What I can give you today is a ‘Rough Order of Magnitude’ range based on similar projects we’ve done. That range is $40k-$80k.
If that range fits your budget, the next step is to do a bit more work together to narrow down that cone of uncertainty.”*
Script 2: Defending the Discovery Phase
“Client: Why should I pay for a Discovery Phase? Just give me the final price.”
*“Agency: Right now, we are at the wide end of the uncertainty cone. If I give you a fixed price now, I have to add a massive 50% risk buffer to protect my agency, which means you overpay.
A paid Discovery Phase allows us to do the engineering work to eliminate those unknowns. It moves us to the narrow end of the cone, allowing us to give you a precise, lower-risk price. You pay a small amount now to save a large amount later.”*
The danger of skipping Discovery
The biggest cause of failed software projects is trying to jump straight from Stage 1 (ROM) to coding.
The client gets a ROM of $50k. They pressure the agency to sign a fixed-price contract for $50k immediately, skipping the Discovery Phase to “save money.”
The agency, desperate for the work, agrees.
They begin coding while still at the wide end of the Cone of Uncertainty. Inevitably, hidden complexities arise. The project actually costs $80k to build. The agency either eats the $30k loss, cuts corners on quality, or fights with the client over every change request.
Everyone loses. The only way to safely traverse the cone is through deliberate discovery work.
- Read more on why a paid discovery phase is essential.
How devtimate helps manage uncertainty
Your estimation tool needs to reflect where you are in the cone. Using a complex WBS tool for a ROM estimate is too slow. Using a simple calculator for a Definitive Estimate is too risky.
devtimate is designed to handle all three stages of the cone.
- Stage 1 (ROM): Use AI-powered templates to generate a high-level feature list and get instant, wide ranges based on historical data. Perfect for the first call.
- Stage 2 (Budgetary): Refine the feature list. Adjust the optimistic/pessimistic ranges based on initial conversations to narrow the spread.
- Stage 3 (Definitive): Build a detailed, nested Work Breakdown Structure within devtimate. Estimate every task individually to build a precise, bottom-up quote that you can trust.
devtimate allows your estimation process to evolve alongside your knowledge of the project.
Start managing estimation uncertainty with devtimate.
Checklist
✅ Never give a single number estimate in the early stages of a project.
✅ Always present early estimates as wide ranges (at least +/- 50%).
✅ Adopt standard terminology in your agency: ROM, Budgetary, and Definitive estimates.
✅ Educate every new client about the “Cone of Uncertainty” concept using analogies.
✅ Refuse to sign fixed-price development contracts based on ROM or Budgetary estimates.
✅ Require a paid Discovery Phase to move from a Budgetary estimate to a Definitive one.
FAQ
1. Isn’t “Cone of Uncertainty” just a fancy excuse for not knowing your job?
No. It is an acknowledgment of the reality of engineering. Trying to price a unique software product before you have designed it is like trying to price a custom house before you have the blueprints. It’s professional negligence to pretend you know the price before you know the scope.
2. My clients demand a fixed price on day one. What do I do?
You have two choices:
- Give them a fixed price that is unbelievably high (e.g., 3x your expected cost) to cover the massive risk you are taking.
- Politely decline the project. Clients who demand certainty without paying for discovery are usually toxic projects that will lose you money.
3. How do I show these ranges in a proposal?
Be explicit visually. Don’t just write “$50k.” Write:
- Optimistic Scenario (Everything goes perfectly): $40,000
- Most Likely Scenario: $60,000
- Pessimistic Scenario (Major complexities found): $80,000 This visualizes the cone for them.
4. Does Agile eliminate the Cone of Uncertainty?
No. Agile accepts the cone. In Agile, you don’t try to fix the scope and price upfront. You fix the budget and time (e.g., “$10k per sprint for 6 sprints”) and you adjust the scope as you learn more. You navigate the cone by being flexible on what gets built, rather than trying to predict the future.
5. How long does it take to get to a Definitive Estimate?
It depends on the project size. For a medium-sized project ($50k-$100k), a thorough Discovery Phase to get to a definitive estimate usually takes 2 to 4 weeks of paid work.
Uncertainty is not a failure of your agency; it is a natural property of software development.
By understanding the Cone of Uncertainty and using the right estimate types at the right time, you stop setting yourself up for failure. You move from being a “guesser” to being a professional consultant who guides clients through the complex process of bringing software to life.
Stop pretending you know the future. Start managing the uncertainty. Use devtimate to handle every stage of the journey.
