Estimating when you do not yet know enough
A client asks for a rough estimate on a logistics dashboard. They need real-time tracking, route optimisation, driver app, and a billing module. They want a number by Friday.
We could give them a number. It would be a guess dressed up with confidence. The honest answer is that we do not yet know enough to estimate, and pretending otherwise sets up both sides for a bad six months.
Here is how we handle this, and what we tell the client.
**The first call is free, the second is not.**
On the first call, we listen for half an hour and ask questions. We are trying to find out what is solid and what is vapour. Solid: "we use Razorpay, webhooks are already wired." Vapour: "route optimisation, something with maps." We do not estimate on this call. We tell the client we will send a discovery proposal.
Discovery is a paid engagement, usually five to ten days at our standard rate. We tell the client this upfront. Some push back. We explain that the alternative is an estimate with a 2x to 5x margin baked in to cover what we cannot see, and that margin is money they pay either way. Discovery lets us shrink the unknown and give them a tighter number. Most clients accept this once we frame it as risk transfer.
**What we do during discovery.**
We write down every assumption and every open question in a shared document. We interview the people who will actually use the thing, not just the person signing the cheque. We look at existing systems, data exports, API docs. We build a thin vertical slice if the architecture is unfamiliar.
The output is not a spec. It is a scope document with three sections: what we know, what we assume, and what we need to decide before we can commit to a fixed price. Each item in the "need to decide" section has a name and a date next to it.
**How we talk about the number.**
When we do give an estimate, we give a range, not a point. We say: this is ₹14 to ₹18 lakh, six to eight weeks, based on the scope document dated such-and-such. If the open questions resolve in a particular direction, it could be ₹22 lakh. We do not hide that.
We also tell the client what is excluded. Third-party costs, data migration from their old system, changes to the scope document after sign-off. These are not footnotes. They get their own section.
**When we get it wrong.**
We recently estimated a Shopify-to-custom-ERP migration at three weeks. It took five. The reason was that the client's product data had four layers of variant inheritance we did not surface during discovery because we did not ask the right person. We absorbed the cost. We told the client on day twelve, not day twenty-one. We sent a short note explaining what we missed and what we were doing about it.
That conversation was uncomfortable. It was also the conversation that got us retained for the maintenance contract. The client later said the thing they valued was that we told them early.
**What we do not do.**
We do not bid on projects where the client refuses discovery and demands a fixed number before we have seen their data. We have made this rule after breaking it twice and regretting it twice. The cost of a bad estimate is not just money. It is the relationship, the reference, and six months of arguing about scope.
A three-person team cannot absorb a 3x miss. A larger shop can bury it in overhead. We cannot. Our estimates have to be honest about what we know and what we do not, and our clients have to be willing to pay for the work of finding out.