Not wrong in the sense of obviously broken. Wrong in the sense that the software doesn't solve the problem the client had. It solves the problem they described, which turned out to be different.
That gap opens in the first conversation, when someone says "we need a dashboard" and you say "sure, let's build a dashboard." You've already missed the step that matters: finding out why they need a dashboard and what problem it's actually supposed to solve.
The first engagement is not code
We spend the first engagement writing a spec, not writing code. This takes one to two weeks and involves talking to the people who will actually use the software, looking at what they do today, and asking the questions that usually get skipped when everyone is eager to start building.
The spec is short. One page if possible, two at most. It covers four things.
The problem, in concrete terms. Not "improve operational visibility" but "the ops team spends 45 minutes every morning pulling three reports, combining them in a spreadsheet, and forwarding the result to six people. That process breaks whenever one of the report formats changes." Concrete means someone could verify whether the problem exists without your help.
What's in scope. The features and flows that will be built. Not what we might build someday. What we're actually building in this phase.
What's explicitly out of scope. This is the part people skip. Listing what you're not building forces everyone to agree on what the project is not. It prevents the quiet drift where "well, since we're already in here" adds three weeks to the timeline without anyone making an explicit decision.
Known unknowns. The things we don't know yet that could affect the timeline or the design. A dependency on a third-party API we haven't looked at. A data migration whose complexity is unclear. Naming these early means no one is surprised when they have to be resolved mid-build.
The estimate is a range
After the spec, we produce a timeline. It's a range, not a point. "Four to six weeks" is more honest than "five weeks." The range communicates that there is uncertainty and it sets a realistic floor and ceiling. A point estimate is usually a guess dressed up as a commitment.
Clients sometimes push for a single number. We understand why: budgets are set against numbers, not ranges. But a range with an explanation is more useful than a number that turns out to be wrong. The explanation tells you what drives the uncertainty, which helps you plan for it.
Why this works
The value of the spec is not that it's a legally binding document or a perfect plan. Plans change. The value is that writing it forces a conversation that needs to happen before the project starts. Every time a client has said "that's not what I meant," it has been something we could have caught in discovery if we'd asked one more question.
Every time we've skipped discovery because the timeline was tight or the client seemed confident about what they wanted, we've regretted it. Sometimes within the first two weeks of building.
The discovery phase costs real time and real money. We charge for it. We think that's the honest way to do it. The cost of getting the problem statement wrong is much higher, and it gets paid later, when changes are harder and more expensive to make.