Why We Won't Quote Your Whole Project Upfront

You have a brief, maybe a few sketched screens, and you want one number: what will the entire project cost? It's a fair question. A fixed price looks like the safest way to buy software development. Your budget is locked, and the risk sits with the vendor. We still won't give you that number on day one. Any total we gave you before a project discovery phase would be a guess dressed up as a commitment. 

Below, we explain why that guess costs more than it seems, what discovery changes, and what we can offer if you need a figure for your budget today.

Key takeaways

• A full fixed price quote before discovery is a guess. At the concept stage, estimates can be off by a factor of four either way.
• Software development projects overrun often and unevenly. In Bent Flyvbjerg's research, 18% of IT projects exceeded their budgets by more than 50%.
• Fixed price moves risk to the vendor, and you pay for it through a risk premium, change request disputes or pressure on quality.
• A discovery phase turns a brief into a defined scope, architecture, risk assessment and roadmap, which makes a reliable estimate possible.
• After discovery, a fixed price for a clearly defined MVP or phase is fair to both sides. Later phases can run on time and materials or a fixed budget with flexible scope.
• If you need a budget number now, ask for a rough estimate as a range, a budget-first plan or a fixed budget with flexible scope.

Why a full quote upfront is a guess

At the brief stage, nobody knows enough to price the entire project accurately, including the team that wrote the brief. Steve McConnell's Cone of Uncertainty models this: estimates made at the initial concept stage can be off by a factor of four in either direction. It's a model rather than a measurement, and McConnell describes it as the best accuracy you can hope for at each stage. Real projects can do worse.

The problem isn't new. In a 2014 review for IEEE Software, estimation researcher Magne Jørgensen found that accuracy had barely improved since the 1980s, with average overruns in software development projects around 30%.

Averages also hide the worst cases. Bent Flyvbjerg's team at Oxford analysed a sample of over 5,000 IT projects. They found that cost overruns follow a power-law distribution: many projects overrun a little, while a fat tail overruns massively. In How Big Things Get Done (2023), Flyvbjerg reports that 18% of IT projects overrun their budgets by more than 50%, and that group averages 447%.

Complex projects fare worse. The Project Management Institute's Pulse of the Profession 2026 found that about a third of complex projects fail, nearly twice the 13% failure rate for projects overall.

Executives see the same pattern in custom software. In a 2024 BCG survey, nearly half of C-suite respondents said more than 30% of their technology development projects ran late or over budget. The top causes were business and tech teams disagreeing on objectives, unrealistic timelines and too few resources.

Where does the uncertainty come from? A brief describes what you want. It rarely covers how your data is structured, which third-party APIs behave differently from their documentation, what your users actually need, or which compliance rules apply. Each of those can change the project scope. None of them shows up until someone looks.

The hidden cost of fixed price software development without discovery

A fixed price contract moves uncertainty from the client to the vendor. You pay for that transfer in three ways.

1. A risk premium built into the price

Under fixed price, the vendor absorbs any overrun. A careful vendor therefore adds a buffer for risks it can't see yet. That buffer is rational. A 2015 study in the Journal of Information Technology analysed 33,908 ERP projects from one major vendor. Factors that drive vendor profitability, project uncertainty among them, weighed far more heavily under fixed price than under time and materials. Without discovery, the unknowns are at their peak, and so is the premium.

The opposite case is worse. When several vendors bid on the same vague brief, the lowest price often comes from the most optimistic estimate. Jørgensen calls this the winner's curse and argues that a strong focus on low price raises the risk of project failure. One software manager is quoted in research on how estimates become commitments. His company only won contracts when it was over-optimistic. It usually learned later that the price had been too low.

2. Fights over change requests

A fixed price project usually comes with a fixed scope. Every new idea becomes a potential change request, and every change request is a negotiation. Learning turns into conflict, and the fear of scope creep makes both sides defensive. 

18F, the former US government digital service, addresses this in its budgeting guidance. It notes the long-standing pressure to use firm fixed price contracts on the assumption that they reduce risk. It also calls it a red flag when a supposedly agile vendor talks about change orders.

3. Quality cuts when the budget runs out

When a fixed budget runs low, the vendor has one variable left to squeeze: work you don't see, such as tests, refactoring and documentation. The research here is mixed. A 2010 study of 100 outsourced projects found that vendors staffed fixed price work with better-trained people and delivered higher quality. Another study points the opposite way. A 2012 MIS Quarterly study looked at flexibility in the client–vendor relationship across 105 outsourced software projects. Flexibility improved vendor profitability under fixed price, but improved quality only under time and materials. In our view, the squeeze is most likely when a fixed price was set on a vague brief.

Jørgensen's surveys of Norwegian software projects show a starker gap. In the first of these studies, none of the fixed price projects was rated successful at delivering client benefits, against 59% under time and materials. The author flags this as the most extreme result. Success was also self-reported by clients and project managers. Still, his overall conclusion was that time and materials worked much better for both client and provider. He linked the gap to behaviours fixed price encourages: choosing on price, less client involvement, and treating scope changes as a risk.

Not every study agrees. In 25 NATO military IT projects studied in 2023, fixed price kept cost overruns near zero and even delivered slightly more client benefit. Those projects ran later, though. The authors warn against generalising from such a small sample, yet the pattern fits the argument above: fixed price moved the risk into the schedule.

Fixed price vs time and materials

The project discovery phase: what it is, how long it takes, what it costs

The discovery phase, often called product discovery, is a short, separate stage before software development starts. In it, a small discovery team turns your idea into something that can be estimated. That team usually includes a business analyst, a designer, a solution architect and a project manager, working closely with your key stakeholders to pin down project goals.

Typical project discovery phase deliverables include:

• clarified business goals, project objectives and success metrics
• user and market research on your target audience and their pain points, or a plan to conduct them
• a prioritised set of user stories with a defined MVP scope
• wireframes or a clickable prototype of the key flows
• a solution architecture, a technology stack and an integration map
• a risk assessment covering technical feasibility, delivery risks, dependencies and key assumptions
• a roadmap with a project timeline, time and cost estimates, and a recommended contract model

How long does it take? 

It depends on what's uncertain. A focused MVP with few integrations needs less time than a multi-platform product built on top of legacy systems. For public services, the UK government's Service Manual sets no fixed period, calls 4 to 8 weeks typical and says the purpose of a discovery should decide its length. BCG recommends rigorously time-boxing the discovery stage. Our own product workshops range from a two-day session to a five-day Design Sprint, depending on how much is unknown. Figures quoted by other vendors come from their projects and say little about yours.

What does it cost? 

A discovery phase typically costs a small fraction of the build. It's scoped and priced before it starts, so you know what you're committing to before the larger decision. The more useful question is what skipping it costs. Given the overrun data above, a short phase of analysis costs far less than building the wrong thing at the wrong price.

From discovery to a quote you can trust

After the discovery phase, the estimate covers a list of specific, well-understood pieces of work. Here's how the estimate is built.

1. Feature breakdown. Each user story is split into tasks across design, front end, back end, QA and DevOps, and estimated by specialists from each discipline. Small, concrete items are far easier to estimate than one big idea.
2. Reference projects. We compare the plan with similar projects we've delivered. It's the same principle Flyvbjerg recommends for large projects: find analogous projects and learn from them.
3. Buffers based on evidence. Jørgensen's advice is to set minimum–maximum ranges from historical estimation error rather than expert judgment alone. Buffers go where the remaining risk sits, such as a new integration, instead of being spread evenly.
4. A stated confidence level. As Jørgensen points out, "estimate" can mean the most likely effort, a 50% figure, a planned budget or a price. We tell you which one you're looking at.

This is also the point where a fixed price becomes fair to both sides. McConnell's Cone of Uncertainty poster notes that commitments tied to project completion should wait until work has been done to narrow the cone. Discovery is that work. Once the MVP or the next phase has a well-defined scope, it can be priced as a fixed price project, often paid against milestones. BCG's research adds a useful limit: keep the first release to what can launch in three to four months of development. Later phases can stay flexible.

When we can quote upfront

Fixed price software development without our own discovery isn't off the table. It fits when the uncertainty is already low:

• Small, well-defined scopes. A landing page, a single feature added to a codebase we know, or a migration with clear boundaries.
• A complete specification. If you arrive with detailed business and technical requirements, final designs and technical documentation, most discovery work is already done. We'll still review it for gaps, which is a much smaller job than a full discovery phase.

Procurement research describes the same split. A study of more than 2,000 US Department of Defense contracts found fixed price contracts more likely when a product is easy to specify and produce. Cost-reimbursement contracts were more likely when it wasn't. Custom software development usually lands in the second group. When yours doesn't, we'll tell you.

"But I need a budget number now"

Budgets often get approved before vendors get chosen. Without discovery, here's what we can give you. 

• A ballpark range

Based on your brief and comparable projects, we can give a rough estimate as a range wide enough to be honest. Treat it as a planning figure for your project budget and expect it to narrow after discovery.

• A budget-first plan

Flip the question from "what will it cost?" to "what can we get for this amount?" Basecamp's Shape Up, a product development method, calls this setting an appetite: a time budget decided in advance, which the authors stress is completely different from an estimate. You set the budget. We shape a first version that fits it and your business objectives.

• A fixed budget with flexible scope

We agree the budget and the development team, prioritise the backlog together and build the most valuable features first. The budget stays fixed, and the scope adapts to it. In Jørgensen's surveys, flexible scope was linked to a 29-percentage-point higher share of successful projects. The gain showed up both in client benefits and in budget control. His peer-reviewed survey also found that agile projects without flexible scope or frequent delivery had below-average success in delivering client benefits.

Get an estimate you can actually budget against

Tell us about your product, your budget and timeline. We'll come back with a proposed discovery scope and a first view of what your build could involve. 

Let's discuss your project.

Top AI innovations delivered monthly!

The administrator of your personal data is Miquido sp. z o.o. sp.k., with its ... registered office in Kraków at Zabłocie 43A, 30 - 701. We process the provided information in order to send you a newsletter. The basis for processing of your data is your consent and Miquido’s legitimate interest.You may withdraw your consent at any time by contacting us at marketing@miquido.com. You have the right to object, the right to access your data, the right to request rectification, deletion or restriction of data processing. For detailed information on the processing of your personal data, please see Privacy Policy.

Show more