Estimating software projects without lying to clients
I want to start with an uncomfortable claim: most software estimates are lies, and the agencies writing them mostly know it. Not malicious lies — hopeful ones. The kind where you quietly drop the "hard part" from the scope doc because acknowledging it would lose the deal, and then you rediscover it in week six when it's too late to be someone else's problem.
This post is about how rootsbit estimates projects, why we've stopped lowballing, and the small handful of structural choices that make honesty feel less like a commercial risk.
Why lowballing is a structural failure, not a moral one
The standard agency estimate goes like this: the salesperson writes a scope, the engineering lead reviews it in 20 minutes, a fixed price is quoted, the deal closes, and the team that actually does the work discovers the scope was written by someone who had not yet read the legacy database schema. The agency eats the overrun, the client gets a defensive agency, and the next estimate is written from a position of "we can't lose this one." Repeat for five years and you have an industry.
The fix is not better character. The fix is a structure that makes honest estimates commercially survivable. Three pieces:
- A paid discovery phase that produces a real scope before any build number is committed.
- A time-and-materials default with a not-to-exceed ceiling, instead of pure fixed-price.
- A weekly scope-and-budget review that is built into the contract, not bolted on.
The rest of this post is the detail.
The two-week paid discovery
Every rootsbit engagement starts with a two-week paid discovery. The cost is small — roughly $2–4k — and it produces three deliverables: a written problem brief, an architecture proposal, and a budget envelope with three brackets (good, better, best). The budget envelope is the key innovation. We are not committing to a number; we are committing to a range and to the conditions under which the range holds.
Discovery is paid for two reasons. First, it filters out clients who are not serious. Second, it gives us permission to do the actual work of estimation — read the legacy code, interview the operators, sketch the data model — without pretending we can do it for free in a "discovery call." The Atlassian playbook on project estimation calls this "refining the backlog"; I'd call it "beginning to tell the truth."
A discovery engagement that doesn't change the scope is a failed discovery. If what you learn in two weeks matches what you assumed in the sales call, you weren't listening hard enough.
Fixed-price vs. time-and-materials: the honest map
I want to give you the actual decision matrix we use, because most posts on this topic are smuggled ideology — either "fixed price is the only way to protect the client" or "T&M is the only honest model." The truth is that each model has a specific failure mode, and the job is to match the model to the kind of risk the project carries.
Most of our work is T&M with a not-to-exceed ceiling. Here is the part that matters: the ceiling is not a quote. The ceiling is the number above which we stop and renegotiate. If a project is running at 70% of ceiling at 50% of scope, we trigger a check-in — not when we hit the ceiling. This is a contractual mechanism, not a hope. It is the single change that has most reduced estimate-related conflict in our history.
We reserve pure fixed-price for work that has genuinely low unknowns: a migration with a known source schema, an audit of a known codebase, a consulting engagement with a defined deliverable. Pure T&M, no cap, is for research-heavy work where the scope legitimately cannot be known in advance — a common fraction of AI/ML work in 2026.
The three-bracket budget envelope
When we deliver the budget envelope after discovery, it looks like this (using one real example with names changed):
- Good ($24k): The core flow shipped — login, browse, place order, receive confirmation. No admin surface. No analytics. 10 weeks.
- Better ($38k): Above, plus a role-based admin surface, a real analytics layer, and 2 weeks of post-launch warranty. 14 weeks.
- Best ($52k): Above, plus an offline-first mode, a notification orchestration service, and a 60-day post-launch support window. 18 weeks.
The client picks. We do not recommend. This sounds cold, but it is the most respectful version of the conversation — the client knows their budget and their runway, and our job is to tell them what each tier actually buys, not to persuade them to spend more. A founder who picks "Good" knowing what it lacks is not a disappointed client at launch; a founder who is steered into "Better" and doesn't feel the difference is.
The weekly scope-and-budget review
The contract includes a 30-minute sync every week between the client's product lead and ours, with a standing agenda: what changed in scope this week, what is at risk, and what the budget-to-actual looks like. This is not a status meeting. It is the mechanism that makes the NTE ceiling real — the moment a scope change is going to push into the ceiling buffer, we name it in this meeting, not in week 14.
I tell clients on the first call: "If you ever find out about a budget problem from the invoice instead of from a Wednesday sync, we have failed." So far, that promise has held.
What this costs us commercially
I'll be honest about the trade-off. Structured estimation like this loses us roughly one in four deals at the proposal stage. The client goes to a cheaper agency that quotes a fixed number, takes the engagement, and discovers the scope problem in week six. Some of those clients come back to us in six months. Some don't, and that is fine — they were going to be unhappy clients either way, androotsbit is not built to be the studio that wins on price.
The thing this structure buys us, that we would not trade, is the right to tell the truth. We have written before about what the real cost of building a mobile app in India in 2026 actually is, and that post exists because we have a structure that lets us quote honestly in the first place.
A small checklist for founders
If you're evaluating an agency estimate, here is what I would want to know:
- Was there a paid discovery? If not, the estimate is a guess.
- Is there a written scope signed by both sides, with explicit "out of scope" items?
- Is the budget a fixed number or a range? A range is honest; a single number is a sales artifact.
- What happens if the project hits 70% of budget at 50% of scope? The answer should be a named mechanism, not "we'll figure it out."
- Who, by name, reviews scope changes weekly?
If the answers come back vague or cheerful, the estimate is a lie, however well-intentioned. Reach out if you want a second pair of eyes on one — we do this for free for founders, because the best clients for us are the ones who learned the lesson somewhere else first.
Next in this series: a practical guide to migrating a content-heavy site from Tailwind v3 to v4 with Astro, and what we learned rebuilding this one.