Software Project Cost Estimation: How to Estimate Development Costs in 7 Steps

Software project cost estimation is the process of forecasting the effort, time and money needed to deliver a defined software scope, and stating how confident you are in that forecast. To do it well: fix the scope and assumptions, break the work into small pieces, estimate effort with at least two methods (for example bottom-up and three-point), add the non-coding work such as design, testing and project management, convert effort to cost with real rates, add contingency based on measured uncertainty, and re-estimate as you learn. A good estimate is a range with stated assumptions, not a single number.

Why Software Cost Estimation Is Hard (and Why It Matters)

Software cost estimation is hard because software has no physical size you can measure before you build it, requirements change while you build, and productivity varies widely between teams. It matters because the estimate drives the decision to fund the project, the scope you commit to, the team you hire and the date you promise customers.

The track record is sobering. In a study with the University of Oxford covering more than 5,400 IT projects, McKinsey found that large IT projects run 45% over budget and 7% over time on average, while delivering 56% less value than predicted. The same research found that software projects carry the highest risk of cost and schedule overruns, that each additional year of project length increased cost overruns by 15%, and that 17% of IT projects go so badly they can threaten the existence of the company.

Those numbers are not an argument against estimating. They are an argument for estimating differently: in smaller pieces, with explicit assumptions, as ranges, and with regular re-estimation.

What an estimate is used for

• Go or no-go decisions: is the expected value worth the expected cost?
• Scope decisions: what can we afford in the first release, and what should wait?
• Resourcing: how many people, with which skills, for how long?
• Vendor comparison: are two proposals estimating the same scope?
• Contract terms: fixed price, time and materials, or a dedicated team?
• Tracking: are we on plan, and if not, how far off?

Estimate, target and commitment are not the same

Many budget fights come from mixing three different things. An estimate is an analytical forecast with a confidence level. A target is what the business wants (“we need this by March for under a given budget”). A commitment is what the team promises after reconciling the two, usually by adjusting scope. Keep them separate in conversation and in documents. When a target is lower than the estimate, the fix is a scope or approach decision, not a smaller estimate.

The Cone of Uncertainty: Why Early Estimates Should Be Ranges

At the idea stage, you know very little about the final product, so any estimate has a wide range of possible outcomes. As you complete discovery, design and the first sprints, the range narrows. This pattern is known as the cone of uncertainty, described by Barry Boehm in Software Engineering Economics and discussed in the Carnegie Mellon Software Engineering Institute’s introduction to software cost estimation.

In practice, match the type of estimate to the stage of the project:

Project stage	Estimate type	What you know	How to present it
Idea or business case	Rough order of magnitude	Goals, target users, a list of major features	Wide range, for funding decisions only
After discovery	Budgetary estimate	Prioritized feature list, key integrations, non-functional needs	Narrower range with a list of assumptions
After design and architecture	Detailed estimate	User stories, wireframes, architecture, data model	Range per release, used for contracts and plans
During delivery	Forecast from actuals	Measured velocity, remaining backlog, real risks	Updated every sprint or milestone

Our software product development process follows this pattern: a rough estimate is produced during Initiation, when the product concept, business purpose, technical stack and team are clarified, and it is refined as design and agile development progress.

What Goes Into the Cost of a Software Project

Development effort is usually the largest single item, but it is rarely more than part of the total. Estimates that only count coding hours are the most common source of overruns. Use this list to make sure nothing is missing.

Cost component	What it covers	Often forgotten?
Discovery and business analysis	Workshops, requirements, process mapping, acceptance criteria	Sometimes
UI/UX design	User research, wireframes, prototypes, visual design, design system	Sometimes
Development	Front end, back end, mobile, APIs, integrations	No
Quality assurance	Test planning, manual and automated testing, regression, performance and security testing	Often underestimated
Project and product management	Planning, coordination, reporting, backlog management, stakeholder communication	Often
DevOps and environments	CI/CD pipelines, staging and production setup, monitoring	Often
Data migration	Extracting, cleaning, mapping and loading legacy data	Very often
Third-party costs	Cloud hosting, licenses, APIs, app store fees, payment providers	Often
Security and compliance	Threat modeling, penetration testing, audits, data protection work	Often
Training and change management	User training, documentation, rollout support	Very often
Maintenance and support	Bug fixes, updates, monitoring, small enhancements after launch	Very often

Labor is the biggest input, so use realistic rates. For reference, the US Bureau of Labor Statistics reports a median annual wage of $135,980 for software developers and $104,300 for software quality assurance analysts and testers (May 2025). Those are wages only. If you are estimating an in-house team, add benefits, equipment, office, recruitment and management overhead. If you are estimating an outsourced team, ask vendors for a rate card per role and what it includes.

Software Estimation Methods Compared

There is no single best method. Experienced estimators combine two or three and investigate when they disagree. Here are the four classic techniques, plus the agile methods most software teams now use.

Method	How it works	Best used when	Main weakness
Analogous (top-down)	Base the estimate on the actual cost of a similar past project, adjusted for differences	Early stage, when you have a comparable project	Only as good as the similarity; hidden differences cause big errors
Bottom-up	Break the scope into small work items, estimate each, then add them up	After discovery, when scope is broken down	Time-consuming; tends to miss integration and non-coding work
Parametric	Use a statistical model linking a size measure (function points, story points, screens) to effort	When you have historical data or a calibrated model	Needs good data and a reliable size measure
Three-point (PERT)	Estimate optimistic, most likely and pessimistic values, then compute a weighted expected value and a range	Any stage, especially when uncertainty is high	Still depends on the quality of the three inputs
Story points and velocity (agile)	The team sizes backlog items relatively; measured velocity converts points to time	During delivery, with a stable team	Points are team-specific; useless before the team has a velocity
Expert judgment and Wideband Delphi	Several experts estimate independently, discuss differences, then re-estimate	Novel work with little historical data	Vulnerable to bias and anchoring if not structured

Analogous estimating

Analogous estimating uses a completed project as the reference point. If a previous customer portal took 400 person-days and the new one has roughly 30% more features plus one extra integration, you might start at around 520 person-days and then adjust. It is fast and useful for early go or no-go decisions. Its weakness is that projects that look alike often differ in exactly the details that drive cost: data quality, integration complexity, compliance and team experience.

Bottom-up estimating

Bottom-up estimating breaks the scope into a work breakdown structure: epics, features and tasks small enough that someone can estimate them with confidence (a common rule is no item larger than a few days). The people who will do the work estimate each item, and the estimates are summed. It is the most accurate approach once scope is known, but it systematically misses work that does not appear as a feature: integration testing, environment setup, meetings, code review, bug fixing and release work. Always add those explicitly.

Parametric estimating and COCOMO

Parametric estimating uses a mathematical relationship between a size measure and effort. The best-known public model is COCOMO II. As the SEI explains, a parametric model has three parts: a size metric (such as source lines of code or function points), cost drivers (product, process, personnel and environment factors such as reliability requirements and team experience), and a mathematical relationship. In COCOMO II, effort grows with size raised to an exponent that ranges from 0.91 to 1.23 depending on scale factors, so effort grows faster than size on large or complex projects. The model was calibrated with data from 16 organizations and is fully open, so organizations can recalibrate it with their own history.

Commercial models such as SEER-SEM and TruePlanning work on similar principles. The practical lesson for most teams is not to run COCOMO itself, but to collect your own history: actual effort per feature type, per screen or per story point, so your parametric estimates reflect your team rather than an industry average.

Three-point estimating (and how PERT fits in)

Three-point estimating asks for three values for each work item: optimistic (O), most likely (M) and pessimistic (P). There are two common ways to combine them. The simple triangular average is (O + M + P) / 3. The PERT formula, from the Program Evaluation and Review Technique, gives more weight to the most likely value: expected effort E = (O + 4M + P) / 6, with a standard deviation of roughly (P minus O) / 6. Three-point estimation is a technique; PERT is the broader planning method that popularized the weighted formula. The value of the technique is not the formula, it is forcing the estimator to think about what could go wrong and making the range visible.

Story points and velocity

Agile teams often size backlog items in story points, a relative measure of effort, complexity and uncertainty, using techniques such as Planning Poker. After a few sprints, the team’s average velocity (points completed per sprint) converts the remaining backlog into a forecast of sprints and cost. This is excellent for forecasting during delivery, but it does not work before a team exists. For a new project or a vendor proposal, use bottom-up and three-point estimates first, then switch to velocity-based forecasting once you have three or more sprints of data.

How to Estimate Software Development Costs in 7 Steps

This process combines the methods above into a sequence that works for most custom software projects, from a new product to a rebuild of a legacy system.

Step 1: Define the scope, boundaries and assumptions

Write down what is in scope, what is out of scope and what you are assuming. Include target platforms (web, iOS, Android), user roles, integrations, expected user volumes, languages, compliance requirements, and who provides content and test data. Every assumption is a cost driver; if it changes, the estimate changes. Overall budget constraints belong here too, because they shape scope choices from the start.

A useful format is a one-page scope statement with three lists: included, excluded, and assumptions. Ask stakeholders to sign off on it before you estimate in detail.

Step 2: Break the work down

Create a work breakdown structure: epics, then features, then tasks. Aim for items that take no more than a few days. Map the dependencies between them, because dependencies affect both sequence and cost (waiting time is still paid time). If you are also building a delivery plan, our guide on how to plan a software project covers how the breakdown feeds the timeline and milestones.

Step 3: Estimate effort for each item with three points

Ask the people who will do the work for optimistic, most likely and pessimistic effort for each item, in person-days or person-hours. Use the PERT formula to get an expected value and a spread per item. Large spreads are useful signals: they point to items that need a spike, a prototype or more discovery before you commit.

Step 4: Add the non-development work

Add design, quality assurance, project management, business analysis, DevOps, data migration, security testing and release work. Some teams estimate these bottom-up; others apply ratios from their own past projects (for example, QA effort as a share of development effort). If you use ratios, use your own history, and say so in the assumptions.

Step 5: Cross-check with a second method

Compare your bottom-up total with an analogous estimate from a similar past project, or with a parametric estimate from your historical effort per feature or per story point. If the two differ by a large margin, find out why before you go further. The gap usually reveals a missing feature, an underestimated integration or an optimistic assumption.

Step 6: Convert effort to cost and add contingency

Multiply effort by the rate of each role (or by a blended rate), then add third-party costs such as hosting, licenses and paid APIs. Add contingency based on measured uncertainty: the spread of your three-point estimates and a list of named risks with their likely impact. Keep contingency visible as a separate line rather than hiding it inside task estimates, so stakeholders can see what it is for and how it is used.

Step 7: Document, review and re-estimate

Present the estimate as a range with its assumptions, exclusions, risks and the confidence level. Have it reviewed by someone who was not involved in creating it. Then re-estimate at each milestone (after discovery, after design, every few sprints) and track actuals against estimates. Over time, that record becomes your best estimating tool.

Worked Example: Estimating a B2B Customer Portal

The example below is illustrative. The work items, effort figures and ratios are assumptions chosen to show the method, not benchmarks. Use your own team’s history in real estimates.

Scope: a web portal where business customers log in, view orders and invoices, and receive notifications, with data pulled from an existing ERP system and an admin panel for staff.

Development effort with three-point estimates (person-days)

Work item	Optimistic (O)	Most likely (M)	Pessimistic (P)	Expected E = (O + 4M + P) / 6
Authentication and user roles	4	6	10	6.3
Customer dashboard	6	10	18	10.7
Order history and search	5	8	14	8.5
ERP integration	8	15	30	16.3
Invoice download (PDF)	3	5	9	5.3
Admin panel	5	8	15	8.7
Email notifications	2	4	7	4.2
Total development	33	56	103	60.0

Two things stand out. First, the expected total (60 person-days) is higher than the sum of most likely values (56), because pessimistic outcomes are further from the most likely value than optimistic ones. That asymmetry is normal in software. Second, the ERP integration has by far the widest range (8 to 30 days). That is the item to investigate first, for example with a short technical spike to test the ERP’s API before committing to a price.

Using the PERT approximation, the standard deviation for each item is (P minus O) / 6. Combining them (the square root of the sum of the variances) gives a standard deviation of about 5 person-days for development. So a reasonable statement is “about 60 person-days of development, likely between 55 and 65”, which is far more useful than “56 days”.

Adding the rest of the work

Line item	Assumption used in this example	Person-days
Development	From the three-point table	60
Quality assurance	30% of development (example ratio)	18
Project management and business analysis	15% of development (example ratio)	9
UI/UX design	Estimated bottom-up	10
DevOps and environments	Estimated bottom-up	5
Subtotal		102
Contingency	15% for named risks: ERP API quality, customer data cleanliness, late feedback	15
Total effort		117

To turn effort into cost, multiply each role’s days by its day rate, or multiply the total by a blended rate. Then add third-party costs (hosting, email service, PDF library license if any) and a separate line for post-launch support. If the business target is lower than the result, the conversation should be about scope: for example, launching without the admin panel and managing a few settings directly for the first months.

Cross-checking the example

Suppose a similar portal built last year took 95 person-days in total but had no ERP integration. Adding the expected 16 days for the integration gives about 111 person-days, close to the 117 above. The two methods agree within a reasonable margin, which builds confidence. If the analogous figure had been 70 days, you would have a gap to explain before presenting anything.

Estimating a Rebuild or Legacy Takeover

Estimating a rebuild of an existing system is different from estimating a new product. The scope looks known, because the system exists, but the real behavior is often undocumented, and the data carries years of exceptions. The most reliable way to estimate a rebuild is to audit before you estimate.

A SupremeTech project illustrates this. A long-standing crowdfunding platform, originally developed by another vendor, was built entirely in outdated PHP code with no structured framework. It suffered from instability, frequent bugs and poor scalability, and it could not support new features or user growth. Our team started with a comprehensive technical audit to identify limitations and opportunities, aligned the roadmap with the client, then rebuilt the platform on Laravel and migrated the infrastructure to AWS. You can read the details in the crowdfunding platform rebuild case study.

[SupremeTech detail: how the audit findings changed the scope or estimate for the crowdfunding rebuild, for example features dropped, modules prioritized or effort reallocated, confirmed by the project team]

For a rebuild or takeover, add these items to the estimate:

• Technical audit: code quality, architecture, dependencies, security issues, test coverage and infrastructure.
• Behavior discovery: document what the current system actually does, including undocumented business rules.
• Data migration: profile the existing data early; cleaning is often a large share of the effort.
• Parallel running: the cost of keeping the old system alive and in sync during the transition.
• Knowledge transfer: time with the previous team or internal staff, if available.

If you are taking over a project from another vendor rather than rebuilding it, see our guide on switching software development teams.

How the Contract Model Changes the Estimate

The same estimate leads to different risks and prices depending on the contract model. The table below summarizes how each model uses the estimate. For a deeper explanation of engagement models and pricing, see our guide to offshore software development services, contracts and pricing.

Contract model	How the estimate is used	Who carries estimation risk	Best for
Fixed price	The estimate becomes the price; the vendor adds a risk premium	Mostly the vendor, but scope changes trigger change requests	Small, well-defined scopes
Time and materials	The estimate is a forecast; you pay for actual effort	Mostly the client	Evolving scopes where flexibility matters
Dedicated team	The estimate sizes the team and duration; scope flexes within capacity	Shared, managed through backlog priorities	Long-term products with ongoing development
Phased (discovery, then build)	A small fixed discovery phase produces a detailed estimate for the build	Reduced for both sides	Projects with unclear requirements

How to Compare Vendor Estimates

When two vendors quote very different prices for the same project, the difference is usually in scope and assumptions, not in efficiency. Before comparing totals, ask each vendor the same questions:

• Which features, platforms and integrations are included, and which are explicitly excluded?
• How many person-days of effort are behind the price, broken down by role?
• Which estimation methods were used, and who on the delivery team produced the estimate?
• What assumptions were made about data quality, third-party APIs, content and client feedback time?
• How much contingency is included, and which risks is it for?
• Are testing, project management, DevOps, data migration and post-launch support included?
• How are change requests estimated and priced?

Put the answers side by side in one table. A low quote that excludes testing or migration is not cheaper; it simply moves the cost to later.

Common Software Cost Estimation Mistakes

Most overruns trace back to a small set of repeatable mistakes. Check your estimate against this list before you share it.

• Estimating only coding. Testing, management, DevOps, migration and support are left out, then appear as overruns.
• Single-number estimates. A point estimate hides uncertainty and is read as a commitment.
• Anchoring on a target. The estimate is adjusted to match a budget someone already announced.
• Estimates by people who will not do the work. Sales or management estimates without engineering input are consistently optimistic.
• Ignoring integrations. Third-party APIs, legacy systems and data exchanges are the most volatile items.
• No assumptions list. When scope changes, nobody can show why the estimate changed.
• Contingency as a habit. A flat percentage with no link to risk is either too small or quietly spent.
• Never re-estimating. The day-one estimate is still used months later, after the scope has moved.
• No historical data. Without actuals from past projects, every estimate starts from scratch.
• Treating long projects as safe. McKinsey’s finding that overruns grow with project length is a strong reason to split large programs into shorter releases.

Software Estimation Tools

Tools do not replace judgment, but they make estimates more consistent and easier to track. The right tool depends on your stage and team.

Tool type	Examples	Use it for
Spreadsheet template	Excel, Google Sheets	Work breakdown, three-point calculations, cost roll-up and assumptions in one place
Backlog and planning tools	Jira, Azure DevOps, Linear	Story point estimates, velocity tracking and forecasts during delivery
Estimation sessions	Planning Poker apps	Structured team estimation that reduces anchoring
Parametric models	COCOMO II calculators, SEER-SEM, TruePlanning	Size-based estimates and sanity checks for larger programs
Time tracking	Harvest, Toggl, built-in tracking in project tools	Collecting actuals to calibrate future estimates

A simple estimation template

If you do not have a template, start with a spreadsheet with these columns:

1. Epic and feature
2. Work item description
3. Role (front end, back end, QA, design, DevOps)
4. Optimistic, most likely and pessimistic effort
5. Expected effort (PERT) and standard deviation
6. Dependencies
7. Assumptions and open questions
8. Risk notes
9. Rate per role and cost

Add a summary tab for non-development work, third-party costs, contingency and the final range, and a separate tab listing assumptions and exclusions.

Estimating With AI-Assisted Development

AI-assisted coding is changing how much effort some tasks take, especially boilerplate code, test generation and documentation. That makes historical data from a few years ago less reliable for those tasks. It does not change the need for discovery, architecture, review, testing and integration, which remain human-led. When you estimate a project that will use AI-assisted development:

• Estimate review and testing explicitly; AI-generated code still needs engineer review.
• Separate tasks that AI accelerates well (scaffolding, CRUD screens, tests) from tasks it does not (integration with poorly documented systems, complex business rules).
• Validate any claimed speed-up with a short pilot before you rely on it in a fixed-price contract.
• Budget the running cost of AI tools if they are part of the delivery.

For enterprise systems that will use AI in production, our guide to custom enterprise software development for AI-ready operations explains which architectural work to include in scope.

Software Cost Estimation Checklist

• Scope statement with included, excluded and assumptions signed off
• Work broken down into items of a few days or less
• Three-point estimates from the people who will do the work
• Design, QA, PM, BA, DevOps, migration, security and training included
• Third-party costs listed (hosting, licenses, APIs)
• Cross-check with a second method, with gaps explained
• Contingency linked to named risks and shown as a separate line
• Estimate presented as a range with a confidence level
• Post-launch support and maintenance estimated separately
• Re-estimation points scheduled at each milestone
• Actuals tracked to improve the next estimate

How SupremeTech Approaches Estimation

We start every custom project with a rough estimate during Initiation, once the product concept, business purpose, technical stack and team are clear, and we refine it as design and development progress. Our Technical Leader leads estimation, so the person responsible for delivery is also responsible for the numbers. Development runs in sprints of one to three weeks, which gives regular points to compare actuals with the plan.

For clients in Japan, our business analysts speak Japanese and join requirement meetings directly, which reduces the misunderstandings that most often break estimates. Da Nang is two hours behind Tokyo, so questions raised during estimation get answered the same day. We are ISO/IEC 27001 certified, which matters when estimation requires access to existing systems or data during an audit.

If you have a project to estimate, our product development process page explains how we work, and you can contact us for a free consultation.

FAQ