How to Validate a SaaS Idea From Your Own Pain Point: 5 Tests From 100 Founder Interviews

The short version: A problem you personally have is a lead, not a conclusion. In 100 founder interviews, the ones who got paid did something specific before writing code: they made strangers commit. Fifty pre-orders. A refundable deposit. Twelve booked dates. A fake demo video with 500 people asking them to build it. The ones who didn't do this built for months, usually a year or more, and then found out nobody cared.

Here are the five tests they ran, what each one costs, and the five ways this goes wrong.

What does "scratching your own itch" actually mean?

Scratching your own itch means starting from a friction you personally hit while doing real work or a real hobby, instead of starting from a market you read about.

The distinction matters because it changes who your first user is. When the problem is yours, you already know the workflow, the workaround, and the moment it breaks. Vikash was doing Photoshop mockups for Upwork clients and ran straight into that pain himself. Thomas was an IT admin packaging software for Microsoft Intune. Neither of them researched a market. They were already inside one.

That head start is real. It is also smaller than it feels. Why the pain is yours tells you nothing about whether anyone else will pay to remove it.

How do you know the pain is not just yours?

Five founders in this set answered that question with an action rather than a conversation. None of them ran a survey.

Three things stand out when you line them up next to each other.

First, none of these tests needed a product. Gil had no product. Joseph and Teimmo had a page with one headline and a synthetic voice demo. Alejandro and Mario had a video of somebody doing push-ups.

Second, the cheapest tests produced the fastest signal. The two that took a day or less cost nothing and returned a yes-or-no answer inside a week. Only the pre-sale needed a runway.

Third, every signal was something a stranger did, not something they said. A stranger paid, booked, or left a comment. That difference is the whole point of the next section.

In one line: you are not looking for agreement. You are looking for a transaction, a booking, or a queue.

Which signal counts as proof?

This is where most validation advice quietly falls apart, because the advice tells you to ask people what they think.

Gil, who sold $20,000 of software he had not written yet, was blunt about it in his interview. Asking someone whether they would pay is not just useless, he said. It is dangerous, because it hands you a false sense that the demand is already there. He described the typical answer: "Sure, if it had this one feature, or if I canceled another subscription, I would pay twenty dollars a month." Then you spend three months building, he said, and nobody buys.

His conclusion was that there is one signal, and only one: collect money.

Joseph and Teimmo arrived at the same rule from the other direction. In their words, there is no way to validate demand other than buyers swiping their credit card. So that is what they asked for, on a sales call, before the product existed. Julian took the same test to a live ad campaign for Gravl and had a paid subscription within ten minutes of switching the ads on.

Vikash ran the smallest version of it. He finished 1,800 mockups in thirty minutes with a script he wrote overnight. The client asked how. Instead of explaining, he offered to sell the tool for $300. The client paid immediately. One person, one payment, and Vikash had the evidence that sent him into two months of turning a script into a product. Bulk Mockup now runs at around $12,000 to $13,000 a month.

Now the counter-example, because it shows what a weak signal looks like even when the numbers seem fine. Aayal and Yali built PropGPT V1 over five months. They ran an influencer campaign and converted 45% of visitors into free trials. That looks like a strong signal. But only 13% of those trials converted to paid, and revenue stalled between $1,000 and $2,000 a month. Their own explanation was that the product was bad. They shut off all marketing for four months, rebuilt it, and came back to a conversion rate above 50% and $30,000 to $40,000 a month within ten weeks.

A signup is a compliment. A payment is data. Sounds cold, but it is the one that works.

What does a false start look like?

Five failure patterns kept repeating. Each one is a different place on the same road.

The itch was real. The market wasn't.

Notice what the first column is not. It is not "the idea was bad." Thomas's planner was genuinely useful to Thomas. Flo's accounting app did what it said. George's problem was that a social app needs a network, and one person cannot bootstrap a network.

So the useful question before you build is not "is this a real problem?" It almost always is. The useful question is:

Which of the five ways is this most likely to break?

If it's "only I needed it," a single deposit from one stranger settles it. If it's "nobody heard about it," you have a distribution problem, and no amount of validation on the demand side will fix it.

What should you do before the first line of code?

Three sequences from the interviews, shortest first.

The one-day version (Alejandro & Mario, PushScroll)

1. Cut a fake demo video of the product you haven't built, using stock or AI footage.
2. Post it where your users already are, with a direct question at the end: would you use this?
3. Count the people who ask you to build it.

The three-day version (Brian Shin, Once)

1. Write down a number and a deadline. He picked a count of confirmed event bookings with actual dates on the calendar, before writing any code.
2. Work every channel you already have: personal contacts on X, LinkedIn, Facebook, then cold messages to strangers posting about weddings and parties.
3. Stop when you hit the number. He sent 250 to 300 messages, got 15 replies, and landed 12 confirmed dates.

The few-week version (Gil, Subscribr)

1. Start a new account somewhere your future users gather, with zero followers. Follow everyone relevant in that space.
2. Give away something small but real. He built free tools, ran giveaways, and collected a list of over 1,000 people.
3. Talk to that list one at a time and find out what is actually broken.
4. Do the arithmetic backwards. He worked out that 50 sales would cover three months of living costs, so 50 sales became the target.
5. Sell it. A seven-day window, a lifetime license, and a refund promise. It sold out in two to three days.

And one shortcut worth naming: Vikash never wrote a spec or ran a survey. He did the work manually for a paying client first, and used that client's $300 as the go-ahead. That is the concierge route, and it is the only test on this list that pays you while it validates. It is the least glamorous test here.

What if the pain isn't yours?

Then you have to replace the one advantage you were born with, which is being a user. Two founders did it with outside signals instead.

David Adius is a former quant trader. His customers were women aged 13 to 25 quitting sugar, a group he has never belonged to. He didn't guess. He checked a US quit-vaping app earning $200,000 a month, confirmed rising search interest around sugar-quitting, copied the onboarding flow, and brought a French influencer in on a 50/50 revenue share. Five months and 60,000 downloads later, Stoppr was at $12,000 a month.

George Lampropoulos, at 18 and with no wrestling background, skipped the domain knowledge entirely and went and got someone who had it: the largest wrestling creator on the platform, as a co-founder. Wrestle AI hit $17,000 a month.

If you don't have the pain, you don't get to skip validation. You get to replace it with harder evidence. That trade is the subject of two related articles: copying a validated product into a new niche, and building on top of an existing platform.

FAQ

How many people saying "I'd use this" counts as validation?

Zero. What counts is a number you chose in advance and then hit: a count of payments, deposits, or booked dates. Gil picked 50 sales. Brian picked a count of confirmed bookings with dates. Both numbers came before the work, not after.

Should I ask friends whether they'd pay for it?

Gil's answer is no, and he called it dangerous rather than merely useless. The reason is that friends answer a question about a hypothetical product, and the answer costs them nothing. Asking for a deposit changes the price of the answer.

Isn't it dishonest to charge for something that doesn't exist?

Gil removed that objection with the terms, not the timing. So did Joseph and Teimmo. Gil promised delivery within 60 days and a full refund on request. Joseph and Teimmo asked for a 100% refundable deposit. The buyer keeps the exit. You get the signal.

My problem is genuinely only my problem. Is that fatal?

Not fatal, but it changes the task. You are now in the position David Adius was in: no insider knowledge, so you need an external signal you can point at. Search trends, a competitor already earning, a co-founder who has the audience. The details are in the related article on pre-selling before you write code and in the articles linked above.

How long should this take before I give up on it?

The tests in this set ran from one day to a few weeks. If you chose a threshold and a date and you missed it, that is the answer, and the next step is finding out why the signal was not there rather than building anyway. The deadline rule and the three filters that come before it are covered in the 8 patterns from 100 founder interviews.

---

One more thing. The five tests and the five failure patterns are on one page in the checklist I put together from this analysis. It is free, and it costs you an email.

Get the checklist →

---

Related reading

• How to Find a SaaS Idea That Actually Makes Money
• How to Find SaaS Ideas From Competitors
• Why Do Side Projects Fail?

---

*Every case and figure above comes from founder interviews published on the Starter Story podcast, as reported at the time of recording. I worked through 100 of them case by case, pulled each one into a single sheet, and sorted by where the idea came from. Some companies have changed since; the numbers are not current. This is also a self-selected group of founders who agreed to be interviewed, so the failures here are the ones people were willing to talk about, not all of them.*