This is Episode 1 of The Build — a five-part series where I follow one non-technical founder, from a napkin sketch to paying customers. The founder is real. Her name isn't Asha, but everything else is.
Asha spent nine years as a physiotherapist before she became my client. She had watched front-desk staff at four different clinics fight the same losing battle every single day: a wall calendar, a WhatsApp group, and a shoebox of insurance claim forms. She was certain there was software hiding inside that mess. She called it ClinicFlow.
The first thing she asked me was, "How fast can you start building?" The first thing I told her was, "Let's try very hard not to build anything for two weeks."
That sentence has saved my clients more money than any line of code I've ever written. Because the single most expensive thing a non-technical founder can do is build the wrong thing beautifully. You don't find out it was wrong until the money's gone.
Building is not validating
There's a seductive myth that the way to test an idea is to build a small version and "see if people use it." That's not a test. That's a $20,000 coin flip. By the time you have something to show, you've spent the budget, burned the calendar, and fallen in love with your own product. You'll interpret every polite "looks nice!" as proof.
Validation happens before code. Its whole job is to be cheap enough that you can afford to be wrong. Here's exactly what Asha and I did, in order, over two weeks and about $200.
1. Write the problem in one sentence — and name who has it
Not the solution. The problem. Asha's first draft was "clinics need better software." Useless — too broad to test. We sharpened it to: "A two-room physio clinic loses 30 minutes a day reconciling no-shows and insurance claims by hand." Now it's falsifiable. You can find that person. You can ask them if it's true.
2. Build the promise, not the product
We put up a one-page site in an afternoon. It described ClinicFlow as if it already existed, ended with "Join the early access list," and ran about $80 of local ads aimed at clinic owners. We weren't measuring whether people liked it. We were measuring whether anyone would trade their email for the promise. Forty-one did in nine days. That's not success — that's permission to keep going.
3. Have twelve real conversations
This is the step everyone skips and everyone regrets. Asha called twelve clinic owners. The rule: never ask "would you use this?" People lie to be nice. Instead she asked, "Walk me through how you handled claims yesterday." You're not pitching — you're watching them do the task today, in the real world, with all its annoyances. The truth is in the workaround, not the opinion.
4. Run the concierge test
For one clinic, Asha became the software. For a week she manually did the thing ClinicFlow would eventually automate: every evening she took their no-show list and claim forms and turned them around by hand. It was exhausting and it was the best money we never spent. It taught us which 20% of the work actually mattered — the part you'd later capture in a real 30-day MVP roadmap — long before we'd committed to the $15K–$35K a proper build costs.
The twist: the feature she loved was the one nobody wanted
Asha was sure the heart of ClinicFlow was a slick analytics dashboard — charts, trends, utilization rates. Not one of the twelve owners mentioned wanting it. What they begged for was dumber and uglier: a way to stop the same patient from no-showing twice without anyone noticing. The "boring" reminder feature was the hook. The dashboard she'd designed in her head was a someday-maybe.
If we'd skipped validation and gone straight to building, we'd have spent the first three weeks polishing the exact thing the market shrugged at. That's not a hypothetical. That's the most common way I watch first-time founders burn their runway.
Decide what would make you walk away — in advance
Before any of this, write your kill criteria down, while you're still capable of being honest. Ours were simple: fewer than 25 signups, or fewer than 6 of 12 owners describing the problem as "weekly or worse," and we'd stop. Setting the bar before you have feelings about the result is the only way it means anything. A kill criterion you can move is just a wish.
What to take from this
- The goal of week one isn't progress — it's permission. Cheap evidence that someone, somewhere, has this problem badly enough to pay.
- Watch the task, don't poll the opinion. "Show me how you do this today" beats "would you use this" every time.
- Be the software before you build the software. A week of doing it by hand tells you what to build and — more valuable — what not to.
- Set kill criteria before you have a heartbeat invested. Future-you will be too in love to judge clearly.
Asha cleared her bar — barely, and not the way she expected. The dashboard was out. The unglamorous reminder engine was in. We had permission to build. Which raised the next, harder question: how do you hand a vague idea to a developer in a way they cannot misunderstand?
Next in The Build: The Spec That Survives a Developer — how Asha turned "I'll know it when I see it" into something a stranger could build correctly, on the first try.
If you're sitting on an idea right now and you're tempted to skip straight to "how fast can you start building" — that's exactly the moment to slow down. Send me the one-sentence version of your problem and I'll tell you, honestly, whether it's ready to test or ready to build. That first conversation is free.
