How We Scope and Estimate a Software Project (and Why Estimates Slip)

The first question most clients ask is "how long will it take and what will it cost?" It is a fair question, and it is the hardest one to answer well. Software is made of unknowns, and an estimate given before anyone has looked at them closely is a guess. This article describes how we turn that guess into a plan you can rely on.

Why estimates slip

Estimates rarely fail because developers are bad at arithmetic. They fail for predictable reasons:

Estimates slip for predictable reasons, so name them early.

• The scope was never written down. "A marketplace app" can mean three weeks or three years.
• Hidden work. Authentication, admin screens, email, payment edge cases, deployment, monitoring and data migration are rarely in the first list.
• Integrations. Every third-party system has quirks that are only found by trying them.
• Changing requirements. Learning what users need is part of the project, not a failure of it.
• Optimism. People estimate the happy path, and projects live on the other paths.

Naming these reasons is the first step to controlling them.

Step 1: Discovery before commitment

We do a short discovery phase before we commit to a plan. It usually covers:

1. Goals. What outcome matters, and how will we know it worked?
2. Users and journeys. Who uses the product, and what are the three or four things they must be able to do?
3. Constraints. Deadlines, budget, existing systems, compliance rules and the team that will maintain it afterwards.
4. Risks. The riskiest assumptions and integrations, which we investigate first instead of last.

The output is a short document and a clickable prototype, which costs far less than discovering the same misunderstandings in code.

Step 2: Break it down

We split the product into features, and each feature into stories small enough to finish in a few days. Small pieces are much easier to estimate than large ones, and large ones are where the surprises live.

Must / Should / Could / Won't. Write the last list down too.

Then we prioritise with MoSCoW:

• Must have: the product does not work without it.
• Should have: important, but there is a workaround for launch.
• Could have: nice to have if time allows.
• Won't have (for now): written down so it is a decision and not a surprise.

Most budgets are met by being strict about the first two lists.

Step 3: Estimate as ranges

A single number invites false confidence. We give a range with a confidence level, for example "6 to 8 weeks for the must-have scope". Two things narrow the range:

Ask for a range, not a single number.

• Reference points. We compare each story with similar work we have done before.
• Explicit risk buffers. Integration work and anything new to the team gets a larger buffer than routine work, and the buffer is shown, not hidden.

As discovery answers questions, the range gets tighter. That is a good sign, not a changing story.

Step 4: Plan in milestones

A typical plan for a mid-sized product might look like the chart below. It is illustrative, since every project differs, but the shape is familiar.

gantt
    title 12 Week Project Plan
    dateFormat YYYY-MM-DD
    axisFormat %b %d
    tickInterval 2week

    section Discovery
    Requirements     :a1, 2026-01-05, 2w
    Research         :a2, 2026-01-12, 1w

    section Design
    UX Design        :b1, 2026-01-19, 2w
    Architecture     :b2, 2026-01-26, 1w

    section Build
    Backend          :c1, 2026-02-02, 3w
    Frontend         :c2, 2026-02-09, 3w
    Integration      :c3, 2026-02-23, 1w

    section QA
    Testing          :d1, 2026-03-02, 1w
    Bug Fixes        :d2, 2026-03-09, 1w

    section Launch
    Deployment       :e1, 2026-03-16, 3d
    Monitoring       :e2, 2026-03-19, 2d

Notice what the plan includes besides coding: design, testing, and a launch period with the team on hand. Projects that skip these are not faster, they just discover the cost later.

Choosing a contract model

Model	Works well when	Watch out for
Fixed scope, fixed price	Requirements are clear and stable	Change requests become negotiations
Time and materials	The product is still being discovered	Needs trust and regular reporting
Dedicated team	Long-running product work	You manage priorities actively

Many projects use a hybrid: a fixed-price discovery phase, then milestones or a capped time-and-materials build.

Handling change

Change is normal. What matters is that it is visible. We keep a simple change log: what changed, what it affects, and what trade-off we recommend, either adding time and budget or removing something of equal size. Nothing silently expands.

What you can do to get a better estimate

• Describe the problem and the users, not just the features you imagine.
• Share examples of products you like and products you do not.
• Tell us your real deadline and budget range. It lets us propose a scope that fits instead of a scope that impresses.
• Name a single decision maker who can answer questions quickly. Waiting for answers is one of the biggest sources of delay.
• Be open to launching smaller first. A focused first release teaches you more than a complete one.

Conclusion

A good estimate is not a promise made on day one. It is a range that narrows as the unknowns are removed, backed by a prioritised scope and a plan that includes design, testing and launch. If someone gives you a precise price after a ten-minute call, ask what they have assumed.