How software houses price a project: estimation, risk contingency and what to check in a quote

The procurement manager at an insurance company in Austria presents a proposal for a new agent portal to the board. The quote is €280,000, broken down by module, with a separate line: “risk contingency: 20%”. The CFO reads the table and asks the question almost everyone asks at this point: “Why are we paying for the vendor’s buffer? Strike the contingency and make them fit into €235,000.”

The question is understandable and almost always leads to a worse deal. Contingency in a credible estimate is not hidden margin. It is the explicit price of uncertainty that exists in the project whether anyone writes it down or not. Strike it out and it does not disappear. It comes back as change requests, slipped deadlines, trimmed testing or a team working under pressure at the end and cutting corners. Paradoxically, a quote with explicit contingency is often safer than a cheaper one without it.

This article is for the person evaluating a custom software estimate who wants to understand what is inside it. We cover what a software house’s project price is made of, how vendors estimate effort, how much work sits outside coding, what risk contingency is and how large it should be, which factors drive the price up most and which questions to ask before you compare quotes. We do not repeat the comparison of billing models (team subscription, time and materials, fixed price), which we cover in detail in which IT vendor billing model actually shares the risk. Here we focus on how the number in the quote is produced.

Why can two honest estimates for the same project differ by a factor of two?

Because at the start of a project nobody knows what it will cost, and an estimate is an attempt to put a number on that ignorance. Software engineering has a name for it: the cone of uncertainty. Barry Boehm drew the first version in Software Engineering Economics in 1981, and Steve McConnell popularised it in Software Estimation: Demystifying the Black Art in 2006. According to McConnell, estimates made at the initial concept stage can be wrong by a factor of four on the high side or the low side, a sixteenfold range, and that is the best case in well-run projects (Jeff Atwood on the cone of uncertainty, quoting McConnell). As scope, requirements and design firm up, the cone narrows.

Two caveats are worth knowing. First, the figures in the cone come from experience and judgement rather than a single large measured dataset, so treat them as an illustration of the order of magnitude. Second, the cone narrows only in projects that actively reduce uncertainty by analysing, prototyping and making decisions. In badly run projects uncertainty does not shrink; it lasts until the end.

The second source of spread is how gaps are interpreted. When the RFP says “integration with the policy administration system”, one vendor prices reading data through an existing API, another prices two-way synchronisation with error handling and a message queue, and a third writes the exclusion “integration scope to be agreed”. Each estimate may be honest. They simply describe different projects. We explain how to write a request that narrows this spread in our article on writing a software development RFP.

The third source is how risk is priced. A vendor that takes on scope risk under a fixed price charges more for it than a vendor billing for time actually worked. A vendor with experience of similar projects knows the traps and prices them; a vendor without that experience does not see them and prices lower, which does not mean the project will cost less.

The takeaway for the buyer: a spread in prices is not proof that someone is cheating, but it is a sign that you are comparing different projects or different assumptions. Before picking the lowest number, check that everyone priced the same thing.

What is a software house’s project price made of?

Every custom software estimate, whatever its format, consists of five elements. A credible quote shows them separately, or can show them on request.

1. Build effort. The person-days needed to design and code the features, broken down by module or phase and by role: backend, frontend, mobile, architect. This is the core of the estimate and where most estimation errors are made.

2. Work around the code. Business analysis, interface design, testing (manual and automated), project management, DevOps and environment set-up, deployment, documentation, fixes after acceptance testing. This part is often underestimated or hidden inside the rates, yet in a real project it is a substantial share of the total.

3. Rates. The day rate for each role and seniority level. Rates differ between vendors and countries, but on their own they say little: a team with a higher rate and more experience may deliver a feature in less time with fewer fixes.

4. Risk contingency. Extra effort or money set aside for events that may or may not happen: an integration harder than expected, performance needing optimisation, a change in an external system. More on this below.

5. The vendor’s margin. Profit and overheads: sales, administration, recruitment, bench time between projects. In a day-rate model it is usually inside the rate; in a fixed price it may sit inside the total.

External costs may come on top: component licences, cloud services, tools, certification, penetration tests by a separate firm. It is worth knowing which are in the quote and which you will pay separately.

Why does the breakdown matter so much? Because without it you cannot answer the basic question: is this estimate realistic? A figure of €200,000 can be an honest estimate for a smaller scope or an underestimate for a larger one. Only person-days by role and module let you compare the quote with others and with your own understanding of the project.

How do vendors estimate effort: bottom-up, by analogy or with three points?

Software vendors use several estimation techniques, often in combination. They are worth knowing, because the technique determines how much you can trust the result. Our glossary entry on IT project estimation gives a short overview.

Bottom-up estimation. The scope is broken into small tasks, each is estimated, and the results are added up. It is the most labour-intensive method and usually the most accurate, but only when the scope is known well enough to break down. Its weakness is that it misses the tasks nobody wrote down. The sum of estimates for known tasks is systematically lower than the actual cost, because real projects always include work that was not on the list.

Estimation by analogy. The vendor compares the project with similar ones it has delivered and adjusts for the differences. A good method early on, provided the vendor really has data from similar projects rather than an impression. Ask which projects it compared against and how large the differences were.

Three-point estimation (PERT). Each task gets three values: optimistic (O), most likely (M) and pessimistic (P). The expected value is (O + 4M + P) / 6. This method has a big advantage for the buyer: it shows uncertainty openly. A task estimated at 10, 15 and 40 days is a very different risk from one estimated at 13, 15 and 18 days, even though the most likely value is identical. If a vendor uses three-point estimates, ask to see them. They tell you more than the total.

For example, a vendor estimates a reporting module at 20 days optimistic, 30 most likely and 70 pessimistic, because it does not know whether the source data will need cleaning. The expected value is (20 + 120 + 70) / 6 = 35 days, not 30. Those five days are the price of uncertainty that a single-point estimate would have hidden.

Story points and velocity. Agile teams often estimate in relative points, with cost derived from the team’s velocity over successive sprints. It works well for planning inside a project and less well as the basis for a price before it starts, because a new team’s velocity on a new project is not yet known. For a critical view of which decisions points actually support, see story point estimation is decision theater.

In practice a credible estimate often combines two methods: bottom-up where the scope is known, analogy where it is not, with a cross-check using a second technique. If both give a similar order of magnitude, the estimate is more trustworthy. If the vendor cannot say how it estimated, the estimate is most likely based on gut feeling.

How much work sits outside coding, and why is a quote without it suspicious?

This is the most common reason a cheap quote turns out expensive. Coding features is only part of the work needed to deliver a working system. The rest is:

• analysis and clarification of requirements throughout the project, not just before it;
• interface and user experience design, if the system has users outside the project team;
• testing: writing automated tests, manual testing, regression testing before each release, performance and security testing;
• project management and communication: planning, meetings, reporting, change management;
• DevOps: environments, CI/CD pipeline, monitoring, backups;
• deployment and data migration;
• fixes after acceptance testing and stabilisation after go-live.

What share of this work is reasonable? We know of no credible public study that gives a single figure for all projects, and we will not invent one. As an indicative estimate from market practice: in business applications, work beyond coding is usually at least a third of the total, and more in projects with demanding quality, regulatory or integration requirements. The share grows with the number of integrations, security requirements, the number of environments and how many people on the client side need to be involved.

So a warning sign is a quote in which coding is almost the whole effort and testing and management are token lines. That work will still be done, in one of three ways: as change requests, as unpaid overtime by the team (which usually shows in quality), or not at all, which you discover after go-live. When comparing quotes, line up the share of testing, analysis and management in each. Large differences are a more important topic for discussion than differences in rates.

What is risk contingency and how large should it be?

Risk contingency is the part of the budget set aside for events that may occur in the project, though nobody knows whether or how much. Project management distinguishes two kinds of reserve, and it is worth distinguishing them in quotes too:

• contingency for known risks covers identified events: an integration with an undocumented system, a new technology, a dependency on a third-party vendor. It can be estimated by multiplying each risk’s probability by its cost;
• management reserve covers what nobody foresaw. It cannot be calculated from a list; it comes from experience and from where you are on the cone of uncertainty.

Data on IT projects shows why contingency is needed. Flyvbjerg and Budzier’s study in Harvard Business Review in 2011, covering 1,471 IT projects, found an average cost overrun of 27%, but that average hides a fat tail: one in six projects overran its budget by 200% on average and its schedule by almost 70% (HBR, 2011). An earlier McKinsey and University of Oxford study from 2012 found that large IT projects ran on average 45% over budget (McKinsey, 2012). An estimate with no contingency at all assumes your project will beat the average, and does not say why.

How large should it be? There is no market standard, and any figure given without context would be made up. As an indicative estimate: with a well-defined scope, familiar technology and an experienced team, contingency in the low to mid teens as a percentage is typical. With a scope described in a few pages, unproven integrations, new technology or heavy dependence on client decisions, 30–40% or more can be justified. The size should follow your position on the cone: the earlier you estimate, the larger it is.

A simple example shows how such contingency can be built. Say the base estimate for the portal is 800 person-days. The vendor identifies three known risks: the policy system integration may need 60 extra person-days (50% probability), migrating historical data may take 40 more (40% probability), and performance requirements may force 50 person-days of optimisation (30% probability). The expected value of those risks is 30 + 16 + 15 = 61 person-days, around 8% of the base. Management reserve for the unforeseen comes on top, sized by how early on the cone you are. Contingency built this way can be discussed line by line, and when a risk is eliminated, for example by prototyping the integration, the contingency should fall.

Three questions matter more than the percentage:

1. Is the contingency explicit? Explicit contingency can be discussed. Contingency hidden inside task estimates blurs and is usually consumed whether or not the risks materialise.
2. What is it based on? The vendor should be able to point to the risks it covers. “20%, because we always do that” is a weak rationale.
3. Who decides how it is used, and what happens to the unused part? Under a fixed price, unused contingency usually stays with the vendor, because the vendor took on the risk. In time-based models contingency is the client’s budget, and using it should require approval and a report.

Back to the CFO from the opening: rather than striking the contingency out, ask what it is based on and request a mechanism to control it. If the vendor shows the risk list and agrees that drawing on the contingency requires approval and the unused part is not invoiced, it becomes a management tool rather than padding.

How do rates, team mix and seniority translate into price?

The day rate is the most visible element of a quote and the most overrated when comparing them. A project’s price is rate multiplied by days, and the number of days depends on the team’s experience.

For orientation on nearshore rates from Poland: on our pricing page a senior backend developer costs €335–485 per day, an architect or tech lead €485–650, and a junior backend developer €165–240. These are our rates, not a market average, but they give you a reference point for comparing quotes.

The rate gap between a junior and a senior is roughly twofold, but the productivity gap on complex tasks can be larger, especially once you count rework, code reviews and senior time spent helping juniors. A junior-heavy team has a low average rate but not always a low cost per feature. Conversely, a team of architects only is expensive and unnecessary for simple tasks. A sensible mix has seniors owning the architecture, key modules and reviews, while less experienced engineers deliver well-defined tasks.

When comparing quotes, look at three things. First, the role mix: is there an architect or technical lead, a tester, an analyst, a project manager with a realistic allocation? Second, the seniority mix: how many seniors, mids and juniors, and who works on what? Third, stability: are the people in the quote the ones who will work on the project, and what happens if someone leaves? A team change mid-project costs onboarding time that estimates rarely include.

Two quotes with the same total can carry very different risks: one with a smaller senior team, the other with a larger junior team and a longer timeline. The second is not cheaper; it is just spread differently over time.

How does the billing model change the way a project is priced?

The billing models are compared in detail in a separate article, but one point matters for reading an estimate: the same effort produces different prices under different models, because the risk sits with different parties.

Under time and materials you pay for time actually worked at agreed rates. The estimate is a forecast, not a commitment. Contingency, if any, is your budget for uncertainty. The vendor does not have to add a premium for scope risk, so the estimate may be lower, but the final cost depends on how you manage scope.

Under a fixed price the vendor commits to deliver a defined scope for a defined sum. It takes on the risk of estimating wrongly, so it adds a premium for it, and that is rational. On paper a fixed price is usually more expensive. In practice it can be cheaper with a stable, well-defined scope and more expensive with an uncertain one, because every change becomes a paid change request.

Under a team subscription you pay a fixed monthly amount for a team of agreed composition. Pricing the project becomes a question of how many team-months a given scope needs, and the scope risk sits with you, as with time and materials.

There is also a hybrid that works well at moderate uncertainty: a fixed price for discovery or the first phase, then time-based billing or subsequent phases fixed on the strength of what earlier phases revealed. It moves the big financial decision to the point where the cone is narrower. In custom software development we price on a fixed-price or time-and-materials basis depending on how well the scope is defined, and start with a discovery phase that usually takes one to two weeks.

Which factors push a project estimate up most?

The table brings together the factors that most affect a custom software estimate. The direction and rationale follow from the estimation mechanics above. We do not give a percentage impact for each factor, because it depends on the project and any such figure would be guesswork. The last column is the one that matters most to the buyer.

Factor	Why it raises the price	How the client can reduce it
Vague scope	The vendor adds contingency or prices the broadest reading	MoSCoW priorities, scenarios, an out-of-scope list, a discovery phase
Number and quality of integrations	Undocumented APIs, no test environments, dependence on another vendor	Describe each integration, give access to documentation and a test environment before pricing
Non-functional requirements	High availability, performance and security need costlier architecture and more testing	Numbers instead of adjectives, levels matched to real business need
Data migration	Cleaning, mapping and verifying data is a project in itself	Assess data quality before pricing, decide which data to migrate
Regulation and compliance	Documentation, audits, security testing, logs	Name the specific requirements rather than “compliance with regulations”
Client decision availability	Waiting for decisions is schedule risk someone has to price	A named product owner with real time, response deadlines in the contract
Aggressive deadline	Larger team, parallel work, more coordination, higher risk	Phasing, a minimum release by the deadline, the rest later
Fixed price under uncertainty	Premium for the scope risk the vendor takes on	Fixed price for discovery or phase one, the rest with transparent rates
New or niche technology	No data for analogy, higher specialist rates	A technical prototype before pricing the whole
Onerous contract terms	Heavy liquidated damages, unlimited liability, long warranty	Damages tied to measurable events and capped (see our contract article)

The last row is often overlooked. Contract terms are part of the price: a vendor forced to accept heavy uncapped damages will price that risk. Which terms really protect you and which only raise the price is covered in our article on software development contract clauses that protect the client.

What should you check in a quote before comparing it with others?

These questions are worth asking every vendor, ideally as a form attached to the RFP so the answers are comparable.

On effort:

• What is the breakdown by module or phase and by role, in person-days?
• Which method did you use, and did you cross-check with a second method?
• Which earlier projects did you compare this scope with?
• Which items carry the most uncertainty, and what are their optimistic and pessimistic estimates?

On work around the code:

• How many person-days go to testing, analysis, project management, DevOps and deployment?
• Does the estimate include automated tests, and to what level?
• Does it include stabilisation after go-live, and for how long?

On contingency:

• Does the estimate include contingency, how much and for which risks?
• Who decides how it is used, and what happens to the unused part?

On assumptions and changes:

• What did you assume that was not in the RFP?
• What did you not price?
• How does the change procedure work, and at what rates are changes priced?
• What actions and decisions on our side does the timeline assume?

On the team:

• Who exactly will work on the project, in which roles and at what allocation?
• What happens if someone on the team leaves?

The answers matter more than the final figure. Two quotes with the same price but different assumptions and exclusions are two different prices. A higher quote with explicit contingency, full testing and a named team may turn out cheaper by the end of the project than a lower one that includes none of those.

How do you spot an estimate that will not survive contact with the project?

Some estimates look fine in a table and start falling apart in month two or three. Six signals help you spot them earlier.

A single figure with no breakdown. A vendor that cannot show what the price is made of either does not know itself or does not want you to know.

Precision that does not fit the stage. A quote of “€283,750” for a system described in ten pages suggests accuracy that does not exist yet. A credible early estimate is a range, or a figure with explicit contingency and a list of assumptions. Paradoxically, a range inspires more confidence than a number accurate to the nearest fifty euros.

No risks. If the vendor identified no risks in a project with several integrations and a data migration, it either did not read the RFP or does not want to worry you before signing.

A price well below the others with no explanation. A gap of around a third below the median of the bids calls for a conversation. Sometimes there is a good reason, such as a ready-made component. More often it means a narrower reading of the scope or work around the code left out.

A timeline that does not follow from the effort. If 2,000 person-days are meant to fit into four months, the team must be around 25 people working at full productivity from day one. That essentially never happens; large teams need ramp-up time and more coordination. Divide effort by duration and compare it with the stated team.

No checkpoint within the first few weeks. If the first working slice of the system is due after several months, you will learn about errors in the estimate only when it is too late for a cheap correction.

Each signal is a reason to ask questions, not to reject the quote automatically. A credible vendor can defend its estimate. One that answers “why so cheap?” with “because we are efficient” usually recovers the difference later.

How can you reduce uncertainty before paying for the whole project?

The most effective route to a better estimate is not negotiation but narrowing the cone of uncertainty before the big decision. Four techniques work particularly well.

A discovery phase. A few weeks of analysis in which the vendor works with you to refine the scope, design the architecture, check integrations and estimate the rest. It costs a fraction of the project, and the output, documentation and estimate, belongs to you and can be used with another vendor. After discovery the estimate moves from the wide end of the cone to the narrower part. Our guide to custom software development describes the whole process from discovery to maintenance.

A technical prototype of the riskiest element. If the biggest uncertainty concerns one integration or one technology, build a small prototype of just that first. A few days or weeks of work turn the largest contingency item into a known cost.

Phasing with re-estimation. Instead of one estimate for everything, a fixed price for the first phase and an estimate for the rest, updated after each phase based on the team’s actual velocity. It is fair to both sides: the vendor does not have to price unknowns, and you see whether the assumptions hold before spending most of the budget.

A minimum release first. An estimate split into “must” and “should” lets you launch a smaller, fully working version first and decide on the rest using real usage data. For an MVP, our MVP cost calculator gives you an initial range.

All four techniques share one feature: they move large financial decisions to the point where you know more. Instead of paying for uncertainty through contingency or change requests, you pay to reduce it, which is usually cheaper.

What are the key takeaways?

A software house’s project estimate is not a catalogue price. It is a numerical description of what is unknown at a given stage. The earlier you estimate, the wider the spread and the larger the contingency should be.

Remember six things. First, at the initial concept stage estimates can be off by a factor of four in either direction, so a spread in bids is normal and comparison only makes sense on the same assumptions. Second, the price consists of effort, work around the code, rates, contingency and margin; ask for the breakdown before you compare. Third, work beyond coding is a substantial part of every project, and a quote that barely includes it will grow during delivery. Fourth, explicit risk contingency is a strength of a quote, not a weakness; ask what it is based on and who controls it rather than striking it out. Fifth, the day rate says less than the mix and stability of the team. Sixth, the cheapest way to a better estimate is to reduce uncertainty before the big decision: discovery, a prototype of the riskiest element and phasing.

If you have an estimate in front of you that you cannot assess, or several quotes that differ more than they should, book a call. We will help you break them into their components and show where the differences lie. And if you are considering a custom software development project, we will start with a discovery phase, after which the estimate for the rest is based on knowledge of the project rather than a few pages of description.