Software Project Timeline Estimates: How to Sign One
Two numbers, not one
Ask three teams for software project timeline estimates on the same feature list and you will get three different dates, and the one you sign can still slip by weeks. That is not a scheduling failure so much as a definition failure. Research on estimation keeps finding the same thing: figures made before requirements are defined can be four times too high or a quarter of the real effort, even from skilled estimators. Steve McConnell’s firm Construx has documented this range for years on its Cone of Uncertainty page, and the lesson is not that estimators are bad. It is that the project itself is still undefined, so the honest answer is a range.
We quote two numbers, not one: a range early, a fixed date after the scope freezes. This article shows what that looks like in practice, where it applies, and what it costs you in certainty at the start.
What the research says about software project timeline estimates
The Cone of Uncertainty has been tested across decades of projects, and the shape is consistent. At initial concept, estimates made by skilled people can be off by 4x on the high side and 0.25x on the low side, a total spread of 16x between the high and low figure. Construx is careful about what this represents: the Cone is the best-case accuracy possible at each stage, so a casual estimate can easily do worse.
The same page carries the part most people skip. Commitments made at the concept stage carry an error factor of 2x to 4x, and a meaningful commitment is only possible about 30 percent of the way into the project, once requirements and design have pinned down enough variability. That does not mean a client is wrong to want a date on day one. It means a date promised there is a promise made before the information that would keep it exists.
What we actually write in an estimate
Our first deliverable is not a schedule. It is a scoped estimate. It opens with what is being built, in one paragraph a non-engineer can read, and then names six things:
- What is explicitly out of scope, feature by feature.
- A time range, not a date. Two numbers: we can probably do this in 7 weeks, we will definitely do this in 10.
- The assumptions behind the range, and the dependencies we need from you, each with a date attached.
- A screen list, so the size of the product is visible in pages, not adjectives.
- A maintenance line, kept separate from the build, because the build figure that gets signed is rarely the figure that gets spent once the site is live and needs attention. That separation is why our maintenance and support work is priced on its own.
- A weekly demo commitment, so progress is a fact you see rather than a status you are told.
The range comes after a short design pass, not before it. The range is the promise; the fixed date comes later, on a narrower scope.
The date only appears after the scope freezes
Here is the sequence we run on MVP builds, and the one we would recommend to any founder:
- Week 1 to 2: discovery, design, and the scoped estimate. At the end of week 2 you hold a range and a screen list, and nothing is signed yet.
- At the freeze: you lock the scope. Everything not on the screen list goes to a second phase. The range narrows into a fixed delivery date, and that date is attached to that scope, not to the project in general.
- During the build: weekly demos. If a change lands mid-build, we widen the range visibly and restate the date, instead of quietly absorbing it and hoping.
We wrote the mechanics of the freeze itself in MVP Scope Freeze: What We Cut, Keep and Do Manually. The part that matters here is the ordering: scope first, date second. When the order reverses, the date gets defended by cutting quality in places nobody notices until after launch.
This is the same philosophy Basecamp lays out in Shape Up, chapter 3, where they set an appetite before design: a small batch is one to two weeks of work, a big batch is six, and the time box is chosen before the solution is. Their framing is blunt: an appetite is completely different from an estimate, because an estimate starts with a design and ends with a number, while an appetite starts with a number and ends with a design.
Why we do not quote a date on day one
The honest answer is that we have watched dates set before design break. On a recent rebuild of a dispatch site, the previous build had shipped after a promised date and the owner wrote about it publicly on the company blog. We came in after that, and the pattern matched what we keep seeing on projects we join mid-stream: the schedule was fixed before anyone had counted the screens, and the fixes after launch ate the margin the date was supposed to protect.
On our own builds we have hit this too, most often from the client side: a content dependency slips, a decision on a payment provider takes another week, and the range has to absorb it. A range absorbs a slip honestly. A single date absorbs it by going quiet.
The two-phase structure looks like this:
| Week | What you see | What you can hold us to |
|---|---|---|
| 1 to 2 | Discovery and design sessions, then the scoped estimate | The range, the screen list, the out-of-scope list |
| At freeze | The locked scope and the fixed delivery date | The date, on that scope |
| Build weeks | A working demo every week | The demo, and the date unless scope changes |
| After launch | The maintenance plan, priced separately | The maintenance line in the estimate |
Nothing in that table requires trusting anyone’s optimism. Every row is a document or a demo you can inspect.
Where a fixed date up front is the right answer
Some projects do not get the luxury of two phases, and pretending otherwise would be dishonest. We take fixed early dates in three cases:
- There is a real external deadline, such as a trade show, a compliance date, or a lease that starts on a Monday.
- The product is genuinely small, a landing page or a five-screen site, so design and build fit inside one week and the cone is narrow from the start.
- The client has done this before, has the content ready, and can name every integration on day one.
Even then, the deal is the same shape: the date is attached to a named scope, and the first cut is from the wish list to the core flow. If a trade show is in six weeks, the demo gets built and the admin panel gets done by hand for the first month. Someone types the entries manually and nobody misses it.
A short test before you sign
Whatever team you are talking to, us or anyone else, three questions separate an estimate from a guess:
- Can I see the screen list this estimate is based on? If there is no list, the number is attached to nothing.
- What exactly does this price include, and what happens to the date if the scope changes?
- When do the weekly demos start, and can I see a real build in the first one?
If the answers are a screen list, an out-of-scope document, and a demo in week one, the estimate is grounded in something real. If the answers are reassurances, the number was never connected to a plan.
The estimate that earns trust
A timeline is not a promise about the future. It is a description of who decides what, and when, and what happens when reality disagrees. The estimate we are willing to sign names the scope, gives a range early and a date after the freeze, and puts a demo in your inbox every week so the date never has to be taken on faith.
If you are about to sign a build and the estimate in front of you is a single number with nothing behind it, ask for the screen list and the range. If you want to see how we scope, bring your feature list to a free consultation and we will tell you what we would put in the first phase and what we would leave out.
Frequently asked questions
Why not just give a fixed price and date up front?
Because the research says the error at that stage is measured in factors, not weeks: 2x to 4x is the range Construx documents for commitments made at the concept stage. A fixed date before design is a promise made before the information that would keep it exists. We would rather give you a range we can defend and a date we can hold.
How accurate is the range after design?
After requirements and screens are pinned down, the uncertainty narrows sharply, which is exactly what the Cone of Uncertainty research describes as the payoff for doing the definition work first. In practice, when the scope freezes and nothing is added, the fixed date holds. When scope moves, we widen the range visibly instead of quietly absorbing the change.
What happens if the scope changes mid-project?
The change goes through the freeze: we restate the screen list, widen the range, and restate the delivery date in writing before the work starts. What we do not do is absorb it silently and discover the overrun at the end. The weekly demo is where this gets discussed, because the effect is visible in the build, not buried in a status report.
Do you charge for the discovery and design phase?
The discovery and design pass that produces the scoped estimate is a short, fixed engagement. You come out of it holding the screen list, the range, and the out-of-scope list whether or not you continue with the build. We would rather a client walk away with a usable scope document than sign a number they cannot inspect.
What if we have a hard deadline from day one?
Then we work the fixed-date shape honestly: we name the smallest core product that ships by the date, we cut from the wish list to the core flow, and we tell you what will be done by hand in the first month. A deadline plus a scope plus explicit cuts is a plan. A deadline plus hope is not.