"How long will it take?" is the second question every buyer asks, and it is usually answered with a number the person answering has no basis for. Three months. Six weeks. The figure is picked to sound reassuring, and it sets an expectation the real scope almost always contradicts.
Three things decide the timeline, and features are not one of them
- How many systems you have to integrate with. Each external system is a dependency with its own credentials, sandbox, rate limits and outages, and none of it is under your control.
- How many decisions are still open. A build waiting on someone to decide what happens to an unpaid order is not blocked on engineering.
- How fast your side answers. A question that takes four days to answer costs four days, and this is the single most underestimated factor in every project.
Why a scope produces a date and a feature list does not
A feature list is a wish. A scope is a description specific enough that a different developer could build from it and produce the same thing. Only the second can be estimated, because only the second says what "done" means.
This is why the order matters. Scope first, at no cost. Then one price and one date against that scope. A studio that commits to a date before writing the scope is either padding heavily or setting up a conversation about change requests later.
What to ask instead
- "What would you need to know before you could give me a date?" — the answer tells you whether they intend to scope anything.
- "When will I first see it running?" — early and weekly is a different project from a demo at the end.
- "What happens if you estimated wrong?" — if the answer is a change request, you are carrying the risk.
The honest position is that a date is a commitment, not a prediction, and a commitment can only be made against something written down. Ask for the scope first and the date becomes a real answer instead of a comfortable one.