Previously on The Build: Asha, a physiotherapist turned founder, spent two weeks proving people actually wanted ClinicFlow — and discovered the feature she loved was the one nobody asked for. (Catch up on Episode 1 here.) Now comes the part that quietly decides whether a build succeeds.
Asha had her validated idea. She was ready to hand it to a developer. And this is the exact moment most non-technical founders lose three weeks and a chunk of trust without ever knowing why.
They describe the idea in a paragraph, the developer nods, and six weeks later the thing that comes back is technically what was asked for and completely wrong. Nobody lied. Nobody was lazy. The gap was the spec — or the lack of one.
A spec is not a description. It's a contract against ambiguity.
Here's the trap: founders think a spec's job is to describe the whole product. It isn't. A 40-page document nobody reads is worse than nothing. The job of a spec is narrower and more powerful — to remove ambiguity from the 20% of decisions that are expensive to get wrong, and to deliberately leave everything else flexible.
You're not writing a novel. You're writing the handful of sentences that, if misunderstood, cost a week each.
The four things Asha's spec actually contained
1. User stories, in the user's voice
Not "build a reminders module." Instead: "As a front-desk admin, when a patient is marked no-show twice, I want to be warned before I book them a third time, so I stop losing slots to repeat offenders." That single sentence carries the who, the when, the what, and — crucially — the why. A developer who knows the why makes the right call when your spec didn't anticipate something. And it always misses something.
2. One sentence per screen: what is this screen's job?
For every screen, Asha wrote the single job it does. "The schedule screen's job is to let the admin see today at a glance and rebook a cancellation in under three taps." When a screen has more than one job, that's not a screen — it's two screens fighting, and it's where bloat is born.
3. Wireframes — on paper
We didn't open Figma. Asha sketched boxes with a pen. The point of a wireframe at this stage isn't beauty; it's to force decisions about what goes where before they cost code. Ugly and decided beats gorgeous and vague. A photo of a napkin is a perfectly good wireframe.
4. Acceptance criteria — how we'll know it's done
This is the part that separates a spec from a wish. For each story: a short checklist that has to be true for it to count as finished. "Done" for the no-show warning meant: the warning appears before the third booking, an admin can override it with one tap, and the override is logged. Now "done" isn't an argument. It's a checkbox.
The twist: the most important page was the one that said "not now"
Asha's spec had a section titled Explicitly Out of Scope. Payments. The analytics dashboard. A patient-facing app. Multi-clinic support. Writing down what you're not building is more valuable than another feature, because it's the only thing that protects your timeline from your own enthusiasm — and from a developer who's happy to keep billing for "just one more thing." The decisions you defer here are the same ones you'll choose a tech stack around — so naming them now saves a rebuild later.
What to take from this
- Spec the expensive 20%, not the whole thing. Remove ambiguity where being wrong costs a week; stay flexible everywhere else.
- Write stories with a "why." The why is what lets a developer make good decisions in the gaps you forgot.
- Define "done" before work starts. Acceptance criteria turn arguments into checkboxes.
- An "out of scope" list is a feature. It's the cheapest protection your timeline will ever get.
With a real spec in hand, Asha could finally hand ClinicFlow to a developer — and now you can see how this connects to mapping out a tight MVP scope. But handing it over is where a new fear begins: for the next eight weeks, a non-technical founder has to somehow tell whether the thing being built is on track, drifting, or quietly going sideways — without being able to read a line of the code.
Next in The Build: Watching the Build Without Being Technical — how Asha stayed in control of a project she couldn't read.
If you're about to hand your idea to a developer and your "spec" is a paragraph and a vibe, pause. I'll help you turn it into something that can't be misbuilt — that one document is the difference between a clean eight weeks and a frustrated rebuild. Send me your idea and let's pressure-test it together.
