"We need a system that handles bookings" is not a requirement — it's a wish, and no developer can estimate a wish. The gap between what a client means and what a developer can actually build from is where most quotes go wrong before a single line of code is written, because a vague brief gets a vague estimate, and a vague estimate is the seed of every scope argument that follows it.
The difference between a feature and a requirement
"Customers should be able to book online" describes a feature. It doesn't say what happens when two customers try to book the same slot at the same moment, whether a booking needs approval or confirms instantly, what happens if payment fails after the slot is held, or whether cancellation within an hour of the appointment behaves differently from cancellation a week out. Each of those is an actual decision with actual development cost, and none of them are visible in the one-sentence feature description — they only surface once someone starts building and has to guess, or stops and asks.
Acceptance criteria turn a wish into something buildable
A requirement becomes estimable once it states, specifically, what "done" looks like: given this input, this exact output; given this edge case, this exact behaviour. "A customer can book an appointment" becomes buildable once it reads closer to "a customer selects an available slot, receives a confirmation within 60 seconds, and the slot becomes unavailable to other customers the moment it's selected, not after payment completes." That level of specificity feels like overkill for a small feature and feels essential the first time an ambiguous one causes a two-week argument about what was actually promised.
The ambiguities that reliably cause overruns
A handful of gaps show up in nearly every underspecified project: what happens on an error (does the user see nothing, a generic message, or a specific one), what happens at the edges of normal use (zero results, the maximum allowed input, a duplicate submission), who can see or edit what, and what the system should do when two people try to act on the same record at once. None of these are exotic — they are ordinary situations that happen constantly in production — but they are exactly the situations a one-paragraph brief never mentions, because they only become obvious once someone is actually building the thing.
Why this protects both sides, not just the developer
A detailed requirement isn't bureaucracy for its own sake — it's the document both sides can point back to when a disagreement surfaces later. Without it, "that's not what we asked for" and "that's exactly what you asked for" are both true statements about the same vague sentence, and resolving that costs more time and goodwill than writing the requirement down properly would have in the first place.
Getting this right at the start is part of the same buy, build or configure decision — because even the right choice of approach only produces a system that actually works if what's being built was specified clearly enough to build.
Our software team turns a client's plain description into acceptance-criteria-level requirements before estimating anything, so the quote reflects what's actually going to be built, not a guess at it.
