I've watched three founders do this now. Each one spent six months building. Each one launched to silence. Each one wished they'd started differently.
The pattern is always the same. An idea forms. It feels obvious — like someone should have built this already. So they hire developers, burn through savings, stress-test edge cases, and launch. Then nothing. A few polite signups from friends. A Slack channel that never got used. A bank account that looks nothing like it did at the start of the year.
The problem isn't the idea. It's the order of operations.
The $20,000 Mistake
Take a logistics founder I talked to last year. Eight years in warehouses. Watched managers use spreadsheets, WhatsApp, and guesswork to track stock. He knew there was a better way. He built it. Nobody bought it.
Not because the software was bad. Because the people who said "yes, this is a problem" weren't actually suffering enough to pay money to fix it. Saying yes to a survey is free. Handing over a credit card isn't.
So he spent £22,000 building something for a customer who existed in theory but not in practice.
Validation needs skin in the game. Even a little. An email address counts.
Why an Email Address Is Worth More Than a Survey
A survey response costs nothing. Click, click, submit. People say they'd use a product, pay a subscription, recommend it to their team — without a moment's hesitation. And they mean it, in that moment. But meaning something costs nothing.
An email address is different. It's a small transaction. The person on the other side is saying: I want this enough to give you something I guard. That's a signal. Not a guarantee — but when you're pre-product, signals are everything.
The trick is creating something worth exchanging an email for.
The PDF Validation Method
Here's what I mean. Write a detailed document about the problem your software will eventually solve. Not vague. Actually useful. Two or three days of real work.
Let's say your SaaS idea is a scheduling tool for independent physiotherapy clinics. Your document might be: The Independent Physio Practice Playbook: How to Eliminate Missed Appointments and Fill Your Diary Without Hiring a Receptionist.
The first half is gold. Write about the problem in exhaustive detail. Cover why physio clinics lose 12–18% of revenue to no-shows. Explain the hidden cost of last-minute cancellations. Walk through the manual processes clinics use and exactly where they break. By page six, the right reader is nodding hard — because you get it.
Then the document stops.
Right when the reader is thinking "okay, so what's the solution?" — the rest is locked.
To read the second half, they enter their email.
That's the gate. See if anyone actually wants through it.
How ZipFlipbook Makes This Work
A PDF sitting in Google Drive doesn't give you this. You can't gate halfway through a PDF. You can't track who read it or how far they got.
I use ZipFlipbook for this. Upload a PDF. It becomes a flipbook — the kind that opens in any browser, on any device, without a download. Set the gate at any page. Page 4. Page 7. Whatever makes sense. Reader hits it, wants more, enters email. Takes five minutes to set up.
When they convert, that's your data point. Stack enough of those up and you've got something real to take to an MVP development company or to investors. Not a pitch deck and a prayer. Actual evidence that strangers wanted what you're describing.
You can also see how many people opened the flipbook, how many reached the gate, and what percentage crossed it. That funnel tells you a lot. If people are dropping off before they even hit the gate, the document isn't pulling them in. If they're hitting the gate and not converting, the second half doesn't sound worth it. All of that is fixable before you've written a line of code.
What Makes a Good Validation Document
Three things separate a strong validation doc from a forgettable one.
Specificity first. Don't write "businesses struggle with communication." Write "franchise managers who juggle four WhatsApp groups before Monday morning." The more precise you are, the more the right reader feels like you've been following them around. Broad problems attract broad audiences — and broad audiences don't convert.
Second, numbers. Industry stats, rough figures from conversations you've had, anything that makes the problem feel concrete. A sentence like "independent clinics lose an average of 14% of weekly appointments to no-shows" lands harder than "no-shows are a major issue." The reader checks it against their experience and either agrees or doesn't. Either way, you've made them think.
Third, name the broken workaround. Every unsolved problem has a jury-rigged solution that mostly works and always frustrates. Your target audience is living inside it right now. Name it. They'll feel seen. That's the whole trick.
And the first half has to actually be good. If it's thin, readers won't trust that the second half is worth anything. Make it so useful they'd forward it to a colleague — then lock the next part anyway.
Getting Eyes On It
Once the flipbook is live, get it in front of people. Post it in niche communities — subreddits, LinkedIn groups, Slack workspaces, wherever your audience actually spends time. Send it to 50 people on LinkedIn with a short message: "I've been researching this problem and wrote something that might be useful — happy to share it." Ask your network to pass it along. Give it two or three weeks.
If strangers are giving you emails, you've got something. If no one's converting, that's useful too — you've found out the problem isn't painful enough, or your document didn't land, or the audience you targeted doesn't actually exist in the numbers you assumed. All of that is worth knowing now rather than after a six-figure build.
What Happens When It Works
Say it works. Eighty emails from people who wanted what was behind the gate. Email every single one. Not a template — a real message. Tell them you're building a tool that automates what the second half of the document describes. Ask for twenty minutes. Some will say yes.
Those calls will teach you more than any dashboard. You'll hear the language people actually use to describe the problem. You'll find out which parts of your solution they care about and which they don't. You'll discover what they're currently paying for alternatives — which tells you where your pricing ceiling is.
Then you go to a development partner with something concrete. Not a napkin sketch. A problem that real people confirmed is painful, a solution they said they'd use, and a list of early adopters already waiting.
That conversation goes very differently.
The Actual Point
Don't build yet. Write a PDF first. Gate it. See if anyone reads it — and more importantly, see if anyone gives you their email to keep reading.
That answer is worth more than six months of coding.
