The four-layer estimation template we actually send to new clients, why we include a confidence range, and what we do when the numbers surprise us.

Software estimates have a reputation problem, and it is deserved. Most of them are optimistic fiction dressed up in a spreadsheet. The client hears a single number. The team hears a range with a prayer attached.

We have been doing this long enough to admit that the "one precise number" style of quoting is mostly theatre. Over the years we have settled on a four-layer template we send to every new client, before the contract, so nobody signs a fantasy.

This post is that template, in public.

The problem with a single-number quote

When a vendor writes "LKR 2,400,000" on the last page of a proposal, they have done one of three things:

1. Padded aggressively, so the real number is LKR 1,500,000 and the extra is their buffer for their own mistakes. 2. Quoted the happy path, where nothing is uncertain, no scope changes, and the integrations behave. This project will overrun. 3. Quoted the feature list literally, ignoring the unglamorous 40% of any real project (auth, permissions, backups, deployment, handover). This project will also overrun.

All three options eventually arrive at the same place: an uncomfortable conversation halfway through the build about "additional costs." The only one who escapes that conversation is a vendor who was honest up front.

The four layers we use

Every estimate we send has four layers. Each layer answers a different question.

Layer 1: The feature core

This is what most proposals stop at: a list of screens and behaviours, each with hours.

We write this layer as granularly as we can, but with a strict rule: no feature is estimated in isolation from the data model. If we cannot name the database tables and the key constraints, we cannot estimate the feature yet; we label it *"Discovery required"* and price the discovery separately.

A typical entry looks like this:

• Order management screen — list, filter, detail view, status transitions (`pending → paid → shipped → delivered`), write-access restricted to role `ops`. *42 hours.*

The hours are not wishful. They are anchored to a task we have done before, on a real project with a code reference.

Layer 2: The invisible work

This is the 40% almost every cheap quote silently removes. We list it explicitly:

• Authentication & roles: login, password reset, role matrix, session policy.
• Admin tooling: user list, impersonation, audit log, data export.
• Infrastructure: domain, SSL, database, backup job, monitoring.
• Deployment pipeline: staging environment, deployment script, rollback plan.
• Documentation: handover doc, runbook, known-issues log.
• Handover session: screen share, Q&A, recorded walkthrough.

Every line here has a number. Clients sometimes ask us to delete this section "because we will deal with it later." We do not. Later is where projects die. This is the layer that decides whether the software survives its first year.

Layer 3: The integration risk budget

Third-party integrations are the single largest source of estimate overruns. Not because they are hard, but because they behave differently in production than in their demo.

For every external system (payment gateway, SMS provider, shipping API, ERP, email service, SSO) we add:

• A discovery slice — usually 4 to 8 hours — spent reading their real documentation and building a minimal smoke test against their actual sandbox.
• A risk buffer proportional to how much we have worked with that specific integration. A gateway we ship every month gets a 10% buffer. A regional gateway nobody on the team has touched gets 40%.

We tell the client exactly which integrations are in which category and why. It is the fastest way to turn "why did this cost more than you said" into "we agreed that one was a risk."

Layer 4: The confidence range

This is the layer almost nobody includes, and the one that changes the entire conversation.

Instead of a single number, we quote a range with an explicit confidence:

• P50 (the realistic median) — what the project will cost if nothing unusual happens.
• P80 (the uncomfortable but plausible) — what the project will cost if two of the known risks materialise.
• P95 (the worst reasonable case) — what the project will cost if half the risks materialise and one surprise appears.

A typical final line on our quote looks like this:

• P50: LKR 2,150,000
• P80: LKR 2,600,000
• P95: LKR 3,100,000
• We propose contracting at P80 with a written scope-change process. If we finish under P50, you keep the difference as a credit toward maintenance.

That last clause is the single most powerful change we ever made to our commercial model. It aligns us with the client's interest in the only way that actually matters — financially.

How we handle changes during the build

A contract signed at P80 still meets change requests mid-project. We handle them with a simple written protocol:

1. The change request is logged in the same tracker as the original scope. 2. We estimate it the same way — small feature core, any invisible work it drags with it, risk range. 3. The client approves in writing before work starts. 4. The range is updated in the shared project sheet that both sides can see.

Nothing is done on a handshake in a chat. That is not distrust; it is the memory policy that prevents a chat from becoming a dispute.

What we do when the numbers surprise us

Sometimes, partway through the build, we realise our estimate was wrong — not because of a change request, but because we missed something in Layer 1 or Layer 3. Real engineering teams hit this.

Our rule: we tell the client the moment we know, not the moment the invoice is due.

The conversation goes like this: "We have found X. Here is why our original estimate did not account for it. Here are three options — a cheaper reduced-scope path, a paid-change path at our cost of build (no margin on the correction), and a full re-quote if the gap is larger than 15%." Clients almost always pick option two, because the alternative — a silent overrun discovered at billing — is the one that ruins the relationship.

The honest bottom line

Estimates are not predictions. They are shared assumptions about an uncertain future. The job of a good estimate is not to be right; it is to be inspectable, revisable, and fair when it turns out to be wrong.

If you are evaluating vendors and one of them gives you a single, precise number with no range, no invisible-work section, and no change protocol, you are not looking at a more confident vendor. You are looking at a less transparent one.

If you want, send us a project brief and we will run it through this template for free, even if you end up hiring someone else. The worst case is you leave with a more honest number in hand.

Original Source: How we estimate software projects honestly (the template we give every new client)