Software Project Estimation: How PostMVP Prices Fixed-Price Projects

Software project estimation is the process of converting a defined scope into a time and cost commitment — and it’s the skill that separates fixed-price agencies that deliver from those that don’t. Get it right and you can commit to a number with confidence. Get it wrong and you’re heading for overruns, renegotiation, or a delivered product that cuts corners.

Most software estimates are wrong. Not because the people producing them are incompetent — because the process is broken. Estimates are produced too quickly, from insufficient scope, with optimistic assumptions about unknowns that later become expensive problems.

At PostMVP, we estimate every project using the same structured process. This is how it works.

Why Most Software Estimates Are Wrong

Most software estimates fail because they’re produced before the scope is defined properly. A client wants a number fast; the agency wants to win the deal; so a price is generated from a brief call and a rough feature list. Everyone knows it’s approximate. Nobody says so.

The result is predictable: the project starts, reality diverges from the estimate, and by the time the discrepancy becomes undeniable, both sides are locked in. The client feels misled. The agency feels underpaid. The software usually suffers.

The root causes fall into three categories:

1. Scope ambiguity — requirements weren’t defined precisely enough for estimation
2. Optimism bias — estimators systematically underestimate uncertainty
3. Anchoring — the first number heard in a conversation becomes the reference point, regardless of whether it’s accurate

The fix for all three is more rigorous scoping before any estimate is committed.

PostMVP’s Estimation Process

Step 1: Decompose scope into user stories

Estimation begins after scoping is complete — not before. We take the user story map produced during scoping and ensure every story is written with enough detail to estimate:

• What action is the user taking?
• What system behaviour does that trigger?
• What data is involved?
• What integrations are required?
• What error states need handling?

A story that can’t be answered in these terms isn’t ready for estimation.

Step 2: Rate each story by complexity

We assign each story a complexity rating using a relative scale:

XL stories should either be decomposed into smaller stories or flagged for paid discovery before committing a price.

Step 3: Convert to time using velocity data

We convert complexity ratings to time estimates using velocity data from previous projects. This is why historical delivery data matters — it’s the only way to convert a relative complexity judgement into an accurate time estimate.

Our velocity table is calibrated to our specific team composition and delivery approach. Generic industry benchmarks are not reliable for fixed-price commitments.

Step 4: Assess confidence and document assumptions

Every story gets a confidence level alongside its complexity:

• High confidence — we’ve built this pattern before, few unknowns
• Medium confidence — we know the approach but there are one or two unknowns
• Low confidence — significant unknowns remain; this story needs more investigation

Low-confidence stories are explicitly flagged in the proposal. If a project has more than 20% of stories at low confidence, we recommend a paid discovery sprint before committing to a fixed price.

Step 5: Apply contingency

We apply a contingency buffer to the total estimate. This is not hidden — it’s a line item in the proposal with an explanation.

Our standard contingency is 15–20% for projects with high confidence across the story set. We increase this to 20–30% for:

• Projects with complex third-party API dependencies
• Integrations with legacy systems where documentation is incomplete
• Projects involving regulatory compliance review
• Mobile apps where device fragmentation testing is required

The contingency buffer is not profit — it’s the honest acknowledgement that software estimation is imprecise. Agencies that show zero contingency are either padding the story estimates instead, or will recover the cost through change requests.

Step 6: Produce the estimate

The final estimate document includes:

1. Total fixed price — a single committed number
2. Story-level breakdown — complexity and confidence per story
3. Timeline — duration in weeks with milestone structure
4. Assumptions — what we’re treating as true when producing this estimate
5. Exclusions — what’s not priced
6. Contingency explanation — the buffer and what it covers
7. Change request process — how scope changes are handled

This document becomes the pricing annex to the contract.

What to Ask Any Agency About Their Estimation Process

Before accepting an estimate, ask:

• How long did your estimation process take? (Less than a week for a substantial project = insufficient scope)
• What historical data is your velocity based on? (No data = gut feel)
• What confidence level do you assign each story? (No answer = they don’t do this)
• What contingency is included and why? (Zero contingency = red flag)
• Which stories are lowest confidence and why? (Deflection = they haven’t done the analysis)

An agency that can answer these questions clearly has done the work. One that can’t is guessing.

In Summary

Accurate software project estimation is a discipline, not a talent. It requires defined scope, story-level complexity ratings, velocity data from real projects, honest confidence assessments, and transparent contingency. PostMVP follows this process on every fixed-price engagement — because the alternative is a number we can’t stand behind.