How to Estimate Software Development Costs in 6 Steps

Someone asks what the new product will cost. The team has a feature list, no designs, and no clear idea yet which parts are hard. Whatever number gets said out loud in that meeting is the number people remember, and six months later it comes back as a commitment nobody actually made.

Running out of money is one of the classic ways a software project dies, and it is usually a symptom rather than a cause: the budget was set before anyone knew what they were building. This guide walks the sequence that turns "what will it cost" into something you can defend — a range instead of a price, a scope document to hang numbers on, four ballpark methods and when each is worth the effort, then the switch to story points and velocity once the team is actually shipping. It is written for founders and CTOs who have to justify a budget to people who will not be writing any of the code.

Step 1: quote a range, because that is all the information supports

The instinct at kickoff is to give a single figure. The honest answer at kickoff is an interval, and there is a well-known picture that explains why. The cone of uncertainty was proposed in 1958 as an estimate classification standard for construction work in the chemical industry, and it has since been validated in project management: the spread of plausible outcomes is widest at the planning stage and narrows as the product takes shape.

Read the chart below and the implication is uncomfortable. At the planning stage, the realistic band runs from roughly a quarter of the eventual cost to about four times it. A build you have sized at twelve months could plausibly land anywhere between three months and four years. That is not a failure of the estimator; it is what the available information is worth at that moment. The band tightens through analysis, design and implementation, and a residue of uncertainty survives right up to deployment.

Three things follow for how you present a number:

1. State the phase the estimate came from. "Planning-stage estimate" and "post-design estimate" are different products, and only one of them belongs in a contract.
2. Give the interval, not the midpoint. If you offer a single figure, the listener will treat it as a ceiling. If you offer a band, the conversation moves to what would push it to either end.
3. Agree when you will re-estimate. Put the checkpoints in the plan — after discovery, after design, after the first few sprints — so the update is expected rather than an admission of failure.

Step 2: write the scope down before you price it

You cannot cost a project you have only described in a sentence. Planning starts by taking the big questions — what is this product, who uses it, what has to exist for it to work — and cutting them into pieces small enough to hand to a specific team.

The document that holds those pieces is the work breakdown structure. It is typically one of the first things a project produces, and it can take whatever shape suits the audience: a nested list, a tree diagram, or a Gantt chart. The format matters less than what it encodes, which is a hierarchy of tasks and deliverables. Level one is the project. Below it sit the major areas — software, hardware, testing, support, whatever applies. Below those sit the work items that somebody will actually be assigned.

Two reasons to do this before any estimating happens. First, every method further down this page needs a list of things to attach numbers to, and the quality of the estimate is capped by the quality of that list. Second, the work breakdown structure is what you turn into the first version of the product backlog, so the effort is not spent twice. If you are starting from a blank page, our guide on how to write a software project brief covers the questions that feed this document.

Step 3: pick a ballpark method that matches what you know

There are four established ways to put a first number on the work. They differ in how much information they need and how long they take, and picking the wrong one is how teams end up spending three weeks producing a precise answer to a question nobody needed answered precisely.

Analogous estimating: use a project you have already delivered

This is the household version of estimating. If you take the family on holiday every year, you can guess this year's cost from last year's without opening a spreadsheet. Applied to software, you take a comparable project from the past and pull three numbers off it: how long it ran, how many people it took, and what it cost.

It is rough by construction, and that is the point. It is fast, it needs nothing but an experienced project manager or team lead who has delivered similar work, and it is the only method that works when you have almost no information about the new project.

Two units of measure make it easier to talk about:

• Ideal days. How many days would this take if you worked on it without a single interruption? A designer who has built this kind of page before might say five days for the home page, then double it to absorb the meetings, reviews and context switches that will actually happen.
• T-shirt sizes. List the large features or sections of the app — the epics — and label each one small, medium, large or extra large. Then go back to past projects, see how many days items of each size really took, and convert.

Parametric estimating: turn history into a rate

Parametric estimating is analogous estimating with the arithmetic done properly. Instead of assuming the new project resembles the old one, you extract a unit cost from the old one and apply it to the new size.

The worked example is simple enough to do in a meeting. A comparable build took seven months and cost $500,000, which puts a month of that team's work at roughly $72,000. The new project looks like nine months of similar work, so the ballpark is nine times $72,000, or $648,000.

The unit does not have to be a month. Derive a cost per feature, per screen, or per engineer and you can answer questions the single figure cannot — what happens to the budget if we add two developers, what a second platform adds. That flexibility is also the catch: on a complex project, estimating feature by feature and variable by variable takes real time. If you want current US benchmarks to sanity-check your own rate, we publish what things actually cost by role.

Three-point estimating: price the bad day as well as the good one

Here you produce three numbers rather than one. The optimistic estimate assumes everything lands as expected and no money is wasted. The pessimistic estimate is the bad version: overruns, rework, spending well past plan. The most likely estimate is the ordinary outcome, with the usual non-catastrophic losses that every project absorbs.

Those three feed the PERT formula — program evaluation and review technique — which weights the most likely case four times as heavily as either extreme before dividing by six. It is one of the most widely used estimation techniques in project management and is generally considered among the most accurate, second only to estimating from the bottom up.

Bottom-up estimating: ask the people who will do the work

The bottom-up method starts at the smallest unit of work, gets an estimate for each one, and adds everything up. What makes it accurate is who does the estimating: not the project manager, but the specialists who will personally deliver those tasks. Each team reports how long an activity of that kind takes them, the project manager converts that into money, and the same conversation surfaces the resources and constraints an outsider would have missed. Individual items will still be wrong in both directions; across a whole project those errors largely cancel.

The cost is time. Bottom-up estimating lengthens the planning phase and therefore adds to the project budget before a line of code is written. If the schedule is tight and the stakeholders are not especially exercised about budget precision, spending weeks on it is hard to justify. If the stakes are high and somebody needs confidence that the number will hold, it is the method that earns it.

Whichever you use, be clear about what you now have. A ballpark is an estimate, not a plan. Its only job is to give stakeholders a sense of how much work the project represents. The real cost and effort become knowable during development, which is where the next three steps live.

Step 4: re-estimate in story points once the team starts building

Agile teams break the product into three levels. Themes sit at the top: long-term objectives that shape the product strategy. Themes expand into epics, the large features. Epics contain user stories, written from the user's point of view and describing what someone wants and why. A login feature might be five user stories; password recovery might be two.

Stories are the unit development actually gets measured in, and the measure is story points. A story point is not an hour and not a day — it is a relative rating of complexity. One is a simple task; eight is a substantially harder one. The technique has been in use in agile teams for well over fifteen years, and it exists precisely because absolute time estimates invite arguments that relative ones do not.

Complexity is subjective, so the rating is a group decision. The usual mechanism is planning poker, and it runs like this:

1. Every team member holds a set of cards — numbers, or t-shirt sizes, or whatever scale the team has agreed on.
2. The product owner reads a user story from the backlog and the team talks it through.
3. Each person privately picks the card they think matches its complexity.
4. Everyone reveals at once. Matching cards mean you have your estimate and can write it down.
5. A spread means another round of discussion and another vote.

The spread is the valuable part. If one engineer says two points and another says nine, they are not disagreeing about effort — they are holding different information. The low vote often knows a library that does most of the job. The high vote has usually spotted a risk nobody else has mentioned yet. Neither of those surfaces if a manager assigns the number alone. Planning poker works best in small teams that already know the project and each other, which is also when that hidden information is worth the most.

Step 5: convert story points into weeks using velocity

Points are useless to a stakeholder until they become a date. The bridge is velocity, and it needs one more ingredient: the sprint. Sprints came out of scrum and are fixed blocks of time, typically between two weeks and a month, in which the team commits to a set amount of work.

Velocity is simply how many story points the team completes in one sprint. Add up the points across every story you intend to build, divide by velocity, and you have a number of sprints. Multiply by sprint length and you have weeks.

The arithmetic below is the whole method. Two hundred story points of backlog, a velocity of twenty points per sprint, gives ten sprints. At two weeks each that is twenty weeks. Then add the sprints that are real work but produce no stories: one at the start of the project and one for release preparation. The answer you hand over is twenty-two weeks, not twenty.

Two caveats keep this honest. Velocity is measured after the fact, so the first couple of sprints are a guess and the number only becomes reliable once the team has a track record. And a team's velocity is its own — comparing it to another team's is meaningless, because the point scales are not calibrated against each other.

The same arithmetic answers the reverse question. If the deadline is fixed at fifteen weeks, work out how many sprints that allows, multiply by velocity, and you know how many story points fit. Everything beyond that has to come out of scope, or you add people to raise velocity and accept the larger budget, or the date moves.

Step 6: trade scope, cost and time instead of quality

Projects do not run to the original plan. Stakeholders take an extra week over the design review. A dependency turns out to be harder than the spike suggested. The estimate has to move, and the only question is which direction you let it move in.

The project management triangle puts scope, cost and time at the corners with quality in the middle. Pull one corner and at least one other has to give:

• More features means more time, or more budget, or both.
• An earlier date means cutting scope to the features that matter for that date, or hiring more developers and paying for them.
• A fixed budget means the scope and the schedule are the variables, and somebody has to prioritise.

Quality is not on that list on purpose. It is the thing the three levers protect, and a team that quietly trades it is choosing a bill that arrives later, in support load and rework, rather than one that shows up in this quarter's budget.

Practically, this is the project manager's standing job: track what the team is actually delivering, update the estimate as the sprints report in, and bring stakeholders the change together with two or three options rather than a problem. None of it works on a fixed-cost contract with detailed specifications locked in advance — there the corners are nailed down and the only remaining variable is the one you did not want to trade.

Where estimates go wrong

Four failure modes account for most of the damage, and none of them is a maths error.

• The planning fallacy. Described in 1979, it is the finding that people expect to finish tasks sooner than they actually do, in professional and personal life alike, and rarely consult their own record of similar tasks before answering. Optimism is the default setting; the correction is to look at what the last three comparable projects actually took.
• Quoting to keep the room happy. A team that knows the proposed budget is too low but wants to stay on the project will sometimes agree to it anyway, betting on fixing the gap later. The gap does not get fixed later.
• Demanding an exact figure too early. Discovery can take weeks or months to establish even a fraction of what has to be built. Stakeholders rarely want to wait that long and still want a realistic number, which is the situation the range in step 1 exists to handle.
• Treating the ballpark as the plan. The first number tells stakeholders roughly how much work the project represents. It is not a schedule, and it is not a commitment on any individual feature.

An estimate you can defend beats a number you can only repeat

The sequence is short. Give a range and name the phase it came from. Write the work breakdown structure so there is something concrete to price. Choose the ballpark method that fits the time you have, from a fast analogous guess to a bottom-up roll-up when the stakes justify it. Then, once the team is building, switch to story points, let velocity turn them into weeks, and re-forecast every sprint. When something moves, move scope, cost or time deliberately — and say which one you moved.

Most of this depends on having a team with a track record you can estimate from, which is the part that is hard to fake on a first project. If you are still assembling that team, we match US companies with vetted developers and project managers who work this way — see how it works.