How to Estimate Software Development Costs Before You Sign a Contract

By Obaid Tariq, Founder & Lead Engineer · Published 20 October 2026

Disclosure: AI Dev Planner quotes for software projects, so we are one of the companies you might compare using this guide. The method works the same whoever you hire. See our disclosure policy.

The short answer

You estimate software development cost before signing by turning your brief into a list of features and risks, getting each one sized as a range rather than a single number, multiplying by the team's rates and adding an explicit contingency for what is still unknown. An honest estimate is a range that narrows as decisions are made, which is why a short paid discovery phase often saves money. Projects overrun mostly because scope was never written down, unknowns were priced as certainties, change control was missing, or the quote left out work such as testing, deployment and project management.

How do you estimate software development costs before signing a contract?

Write a brief with explicit scope and exclusions, then ask for an estimate broken down by feature or milestone, with each item given as a low-to-high range, the assumptions behind it and the team's rates. Add a named contingency for the unknowns, and compare quotes on the same scope rather than on the bottom line. If the uncertainty is too wide to price, pay for a short discovery phase first and estimate again from what it produces.

Why a single number is the wrong thing to ask for

Early in a project, nobody knows exactly what will be built: integrations behave differently from their documentation, users change their minds, and some decisions have not been made yet. An estimate that ignores this is not more accurate, only more confident. Ask for ranges, and expect the range to narrow as decisions are made. A supplier who gives a precise fixed price from a one-paragraph brief has either padded it heavily or not understood the work. When the unknowns are too large to price, a short discovery phase comes first; the UK government's Service Manual describes discovery as understanding the problem before you commit to building, says teams should not start building during it, and says stopping at the end of discovery is not a failure if the research shows that is the best thing to do.

A five-step method you can use with any supplier

Write the brief. Users and roles, the one or two core workflows, integrations, data, non-functional needs (security, performance, accessibility) and, crucially, what is out of scope. Our free software requirements document template gives you the structure, and the SaaS MVP planning checklist covers the decisions to make first.
Break it into estimable pieces. Ask for an estimate per feature, screen or milestone, not just a total. Small pieces are easier to size and easier to cut later.
Size each piece as a range (best case to likely worst case) with its assumptions written down, for example "assumes the CRM's API supports webhooks".
Add the work that is not features: design, project management, testing and quality assurance, deployment and infrastructure set-up, data migration, documentation and handover. These are real costs; a quote that omits them has not removed them.
Add an explicit contingency sized to the uncertainty, and agree who controls it. A known reserve that needs your approval to spend is better than padding hidden inside every line.

A worked example, with its assumptions shown

The table below is illustrative only: the hours are invented to show the method and are not a quote or a benchmark. The point is the structure. Multiply each range by the team's blended day or hourly rate to get a cost range, then add contingency.

Illustrative estimate structure for a small SaaS MVP (hypothetical hours, not a quote)
Item	Low (hours)	High (hours)	Assumption that drives the range
Authentication and organisations	24	48	Managed auth provider; high end if SSO is required at launch
Core workflow (3 screens + API)	80	160	Workflow agreed in discovery; high end if approval rules change mid-build
Subscription billing	24	56	Hosted checkout and portal; high end for usage-based pricing
CRM integration	16	64	Wide range because the API has not been tested yet
Design	40	72	Uses a component library; high end for a custom design system
Testing, deployment, project management	60	110	Roughly in proportion to the build; never zero
Total before contingency	244	510	The width of this range is the honest message

How to compare quotes like for like

Questions that normalise software development quotes before you compare prices
Check	Why it matters	Red flag
Same scope?	Quotes priced against different interpretations of a brief are not comparable	No written scope or exclusions in the quote
What is included?	Testing, deployment, project management and post-launch support are often left out of cheaper quotes	Line items only for visible features
Who does the work?	Rates mean little without the seniority and the number of people behind them	No named roles; "a team" with no detail
Assumptions listed?	Every estimate rests on assumptions; hidden ones become change requests	No assumptions section at all
Pricing model and change control	Fixed price, time and materials and capped hybrids move risk in different directions	No process for pricing and approving changes
Payment schedule	Payments tied to accepted milestones protect you better than payments tied to dates	Large upfront payment before any deliverable
Ownership and hand-over	You should own the code and accounts you paid for	Code in the supplier's repository with no assignment clause

Fixed price, time and materials, or a hybrid?

A fixed price suits small, well-defined work: the supplier carries the risk of overrunning, and prices that risk in. Time and materials suits work where learning will change the plan: you carry the risk but pay only for work done and keep the freedom to change course. For most MVPs we prefer a hybrid: a fixed-price discovery phase, then build milestones that are each estimated as a range, with a cap per milestone and priorities agreed in advance so something can be dropped if an item runs long. Whatever the model, the contract should say how changes are estimated and approved before work on them starts. Our guide to choosing a software development company covers the contract clauses to check.

Getting a ballpark before you talk to anyone

If you only need an order of magnitude for planning, our MVP cost calculator gives an indicative range and timeline from a few questions, and our guide to how long it takes to build an MVP explains the phases. For SaaS-specific budget drivers such as multi-tenancy and billing, see SaaS development cost. Use those to sense-check quotes, not to replace them.

Why do software development projects exceed their budgets and timelines?

Mostly for predictable reasons: scope that was never written down, unknowns priced as if they were certain, no process for approving changes, work left out of the original estimate, and slow decisions on the client side. Large overruns are more common than most buyers expect, so the defence is structural: written scope with exclusions, ranges and contingency, short milestones you accept one at a time, and a list of features you are willing to drop.

Overruns are common, and the tail is long

In a study of 1,471 IT projects published in Harvard Business Review, Bent Flyvbjerg and Alexander Budzier found an average cost overrun of 27%, but the average hid a fat tail: one in six projects was a "black swan" with an average cost overrun of 200% and a schedule overrun of almost 70%. The sample was not made up of startup MVPs, so treat the figures as a warning about risk rather than a forecast for your project. The lesson for a buyer is that the danger is less the modest overrun than the rare, very large one, and that is what contingency, milestones and the ability to stop are for.

The causes we see most, and how to prevent each one

Common causes of software budget and timeline overruns and how to prevent them
Cause	How it shows up	Prevention
Unwritten scope	"I assumed that was included" from either side	Written scope with explicit exclusions, signed before work starts
Scope creep	Small additions accepted informally until they add up to weeks	Every change estimated and approved in writing; a parked list for later
Unknowns priced as certainties	An integration or data migration turns out far harder than assumed	Ranges, a spike on the riskiest item, and visible contingency
Missing non-feature work	Testing, deployment and project management appear as extras	Ask for them as line items in every quote
Slow client decisions	Developers wait days for answers or access to systems	A named decision-maker and agreed response times on both sides
Big-bang delivery	Problems surface at the end, when they are most expensive to fix	Short milestones with working software you review and accept
Choosing the lowest quote	The cheapest bid assumed the least work and recovers it through changes	Normalise quotes on scope and inclusions before comparing price
Technical debt from rushing	Each new feature takes longer than the last	Tests and code review in the definition of done, not as optional extras

Does AI-assisted development change this?

AI tools can make some coding faster, but the main causes of overruns above are about decisions, scope and communication, which AI does not remove. Research on how much AI speeds developers up is mixed, and faster code without strong review can create rework later. When a supplier says AI makes them cheaper, ask where the saving shows up in the estimate and how they control quality. Our guide to whether AI makes software development cheaper sets out the evidence and how to measure savings.

What to do if your project is already over budget

Stop and re-plan before spending more. Ask for an updated estimate of the remaining work as a range, with the reasons for the change.
Cut to the core workflow. Move everything else to a later list and ship what proves the product works.
Check what you own. Make sure the code is in a repository you control and that you hold the accounts for hosting, domains and third-party services.
Decide whether to continue, renegotiate or switch. If trust has gone, our guide to switching development agencies explains how to move without losing code or data.

For a wider look at the problems clients run into with development companies, see software development problems clients face.

Frequently asked questions

How accurate can a software estimate be before discovery?

Not very, and an honest supplier will say so with a wide range. Accuracy improves as requirements, designs and technical unknowns are settled, which is why a short paid discovery phase followed by a re-estimate usually produces a far more reliable price than a quote from a brief alone.

How much contingency should a software project have?

It depends on how much is still unknown. A well-specified project with familiar technology needs less than one with untested integrations or unsettled requirements. Size it from the riskiest items in the estimate, make it a visible line, and agree that spending it needs your approval.

Is a fixed-price software contract safer for the client?

It caps what you pay for the agreed scope, but the supplier prices the risk in, and anything outside the written scope becomes a change request. Fixed price works best for small, well-defined work. For evolving products, capped milestones with agreed priorities often protect you better.

Why are software quotes for the same project so different?

Usually because each supplier interpreted the brief differently, included different work such as testing and deployment, assumed different team seniority, or priced risk differently. Ask each one for the same breakdown, assumptions and inclusions, then compare.

Should I pay for a discovery phase?

If the project is more than a few weeks of work or has significant unknowns, usually yes. Discovery should produce a written scope, key designs or prototypes, a technical approach and a revised estimate. Make sure you own those outputs so you can take them to another supplier if you choose.

Sources

Flyvbjerg and Budzier, Why Your IT Project Might Be Riskier Than You Think (Harvard Business Review, 2011; arXiv version) — Sample of 1,471 IT projects; average cost overrun 27%; one in six projects a black swan with an average cost overrun of 200% and a schedule overrun of almost 70%. Accessed 20 October 2026.
GOV.UK Service Manual: How the discovery phase works — Understand the problem before committing to build; do not start building in discovery; stopping after discovery is not a failure. Accessed 20 October 2026.

Recommendations without a source are AI Dev Planner’s own engineering opinion. Platform features and prices change; check the linked pages for the current position. Found an error? See our corrections policy.

Browse all 76 questions in the SaaS & web development guide.

Want an estimate you can actually check?

Send us your brief. We will reply with a feature-by-feature range, the assumptions behind it, what is excluded and where a short discovery phase would firm it up.

Get a broken-down estimate MVP development services