Ask most developers what kills a project's timeline and they'll point to something technical — a tricky integration, a legacy system that fights back, a dependency that breaks. In practice, the bigger killer is usually simpler and less interesting: nobody agreed on the scope before work started.
Vague scope feels comfortable. That's the problem.
A vague brief is easy to say yes to. "Build us a dashboard" or "add AI to our workflow" sounds like a clear enough starting point, and it's tempting to just start building something and iterate from there. The trouble is that everyone involved fills in the gaps differently — the client pictures one thing, the person building it pictures another, and neither finds out until there's a half-built system that doesn't match what anyone actually meant.
The fix isn't more documentation. It's asking uncomfortable questions early, before either side has invested anything in a particular answer.
The questions that actually matter
Who is this for, specifically? Not "our team" — which person, doing which task, on which day. A dashboard for a finance lead checking numbers once a week is a different build than one for an ops team watching it live all day.
What does "done" look like? Not a feature list — a specific scenario. "Done" means a named person can complete a named task without asking anyone for help. If that scenario can't be described concretely, the scope isn't actually clear yet, regardless of how detailed the feature list looks.
What's explicitly out of scope? This one gets skipped most often, and it's usually the most valuable question in the whole conversation. Saying what won't be built protects both sides from the slow scope creep that turns a two-week project into a two-month one with no one quite able to point to when it happened.
Why this happens before pricing, not after
An estimate built on a vague scope is really just a guess with a dollar sign in front of it. Getting specific first means the number that comes back afterward actually means something — and it means that if the scope changes later, which it often does, everyone can see clearly what changed and why the price or timeline moved with it.
None of this is complicated. It's mostly just the discipline of asking the boring questions before the interesting work starts, instead of after.