Idea Validation Playbooks
How founders pressure-test an idea before building it — the demand signals worth chasing, the cheap experiments that surface real intent, and the traps that waste months. Every tactic below is quoted directly from a founder podcast and linked to its source.
245 tactics · page 1 of 9
“I created the Stripe payment link, we put it online and it made $220,000 in one day just from pre-orders… it was just a 5 minute Loom video.”
A 5-minute Loom pre-sold $220K in a day — no product needed
Package existing expertise into the smallest possible artifact and put a payment link behind it. Before building anything, a Loom plus a Stripe link can tell you in 24 hours whether people actually want what you're selling.
“For years this is what people asked they asked us to build like we're like please build me a system where I can talk to a human tutor we built it no one used it.”
Users Begged for Human Tutors — Duolingo Built It and Nobody Used It
Duolingo built on-demand human Spanish tutoring after years of user requests. When the button appeared, users would connect, see a real human face on screen, and immediately try to leave — too intimidating to speak a foreign language with a stranger watching. Jim's lesson: never take feature requests at face value; test the emotional reality, not just the stated preference.
“I didn't build any product, I didn't have anything. I just had a glimpse of what a product can look like in a landing page, and people were signing up from left and right.”
Ship a landing page first — let strangers prove demand before you write code
Real validation comes before the product, not after. Ship a landing page that shows what the tool could look like, then watch whether strangers sign up unprompted. Signups from a page alone are the green light to actually build.
“When you find a niche that's heavily monetized with physical products, that's a good indicator that the niche converts. It's also a good indicator that you can probably build a software or application to solve a problem within it.”
Niches heavily monetized by physical products signal a software opening
When a niche is already monetized by physical products like skincare, supplements, or beauty tools, demand and willingness to pay are already proven. That's a green light to build software for the same audience — you're not creating want, just redirecting spend.
“My validation process primarily looks like a deep dive into the niche on social media. I'll create an account, say Cal, and then purely consume nutrition and dieting and calorie counting weightlifting content… and then think about what I want, and just build that.”
Become the target customer on social before you write a line of code
Spin up a fresh account, feed the algorithm only that demographic's content, and absorb their language and pain points until you start wanting things yourself. Then build what you, the simulated customer, would actually buy.
“No one was building a product around it. I knew this is a good idea — I didn't do any validation or anything. I just said, if I don't do this, someone else will.”
Skip validation when the gap is obvious — if you don't build it, someone else will
When you see demos of a capability but no real product wrapping it, that gap itself is the signal. Treat speed as the validation — if you don't build it, someone else will, and the window closes fast.
“Find something that you can't build yet and the only bottleneck is the AI model itself… then start building that and just bet that in a year you're going to have GPT-5 capable of doing that, and you have one full year as a head start.”
Bet on the model curve — build for the capability that is coming next
Pick an idea that the current models can almost — but not quite — handle. By the time the next model lands, the product is ready and you have a year-long head start on everyone who waited for the capability to arrive.
“I usually find ideas when I encounter some problem, either me or friends… I ask a lot of questions: really, you have this problem? But how frequent? Am I able to do better? Am I able to build something around it? Am I able to monetize it?”
Don't just ask if a problem exists — ask how often it actually happens
Good ideas come from real problems, but frequency is the filter. Interrogate how often the pain shows up, whether it can be solved better, and whether anyone will pay before committing time to building.
“I build an MVP and then I show it to a few real estate agents that I found online or in personal network. People say that's awesome, I want to buy it now, and they actually paid for this. So that was the validation.”
Real validation is one customer who actually pays — not a survey
Validation is not a survey or a waitlist. Build a rough MVP, put it in front of the exact people you think will buy, and treat actual payment as the only signal that confirms the idea.
“I went to Google and I saw so many competitors. It means there are people paying. That was a good heuristic to evaluate… Having a niche with competitors is good — you can probably also find some numbers, see how many customers they have.”
A crowded search result means demand exists — count competitors before niching down
A crowded search result isn't a red flag — it's confirmation that buyers exist and have wallets open. Use competitor counts and rough customer numbers as a heuristic to estimate whether the niche is big enough to hit a target MRR.
“People are really nice — some can just pay you, even for a non-existing product. But you still don't know if they'll use it… Once you have at least 10 paying customers from outside your network… that's, for me, the ultimate validation.”
Ten paying strangers from outside your network is the only real validation
Friendly opinions and even pre-orders from your network aren't proof anyone really wants the product. The real validation bar is ten paying customers from outside your network who found the product themselves and stuck around to use it.
“I had so many failures in so many startups at first, and then I just paused and I said: okay, let's read some books — let's read about Traction for marketing, let's read about $100M Offers… and then I started to make smarter decisions.”
Half your time learning, half building — that is how you stop picking bad ideas
Repeated startup failures usually come from jumping into ideas without understanding distribution. Pausing to study marketing, sales, and offer design — roughly half your time on learning, half on building — produces sharper idea selection and faster traction the next time around.
“First, validate the idea by doing it for people in a way that either isn't for sale or doesn't scale.”
Validate by doing the work manually for free — in a way that doesn't scale
Don't ship a product to test the idea — do the work yourself for free, by hand, for the exact people you'd serve. If that doesn't pull demand out of them, no automated version will. Once it's pulling, then you can automate.
“The question that people should be asking themselves is, what do I do better than anyone else in the world? And then just help people, put good things into the world that are helpful, for free, for the purpose of being helpful.”
Ask 'what do I do better than anyone?' — then give it away free until demand monetizes itself
Pick the one thing you can do better than almost anyone, then give it away free until it's obvious the demand is real and large. The free help compounds into a trustworthy reputation, and eventually the audience itself will push you to monetize it.
“Having run into this problem on Airtable before, I thought — could I build this for this new platform that's taken off?… I kind of validated it by looking at their forums to see what problems people were running into.”
Mine the host platform's forums — repeat painpoints are your validation signal
Validation doesn't require surveys or cold outreach. Pair a pain you personally hit with public evidence of others complaining about the same problem on the host platform's forums. That's enough signal to start building.
“Step three is — you want to borrow a proven add-on or pattern from a more established platform. For me that was obviously Google Sheets and Airtable. And borrow all the UX from that, as well as making it feel native.”
Port a proven add-on pattern from a mature platform to a younger growing one
The cleanest shortcut is finding a successful add-on on a mature platform and porting its pattern to a newer, growing one. Price points, UX, and demand transfer over wholesale, leaving only execution risk to absorb.
“I set up a pre-sale… 50 licenses at kind of an absurdly low price… pretty quickly it sold out within 2 or 3 days, and I made my first $20,000 before the idea was even built.”
Pre-sell 50 lifetime licenses — collect $20K before writing a line of code
Real validation isn't asking friends or surveying willingness-to-pay — it's collecting money. A tiered pre-sale of 50 lifetime licenses with a money-back guarantee sold out in 2-3 days and netted $20K before any code was written, proving demand and funding the build.
“Step one is you have to build an audience because if you don't have an audience, you don't have anyone to sell to. Step two is you've got to set up an email list and start communicating with people at least once a week.”
Build an audience and an email list before you ever pitch a pre-sale
Validation starts months earlier with audience-building. Post raw build-in-public content, ship free things of value on X, then funnel that attention into a weekly email list — the trust there is what makes a pre-sale convert when launch day comes.
“I started using it, doing some research, I noticed that the workouts were weird and even a bit dangerous sometimes… Okay, this is it: we need to build [the incumbent's] UI/UX with an actual proper workout engine.”
Clone the category leader's UX — then fix the broken core nobody else noticed
Pure copycat builds add no value, but cloning a beloved interface while fixing what's actually broken underneath is a viable wedge. The trigger to go all-in came from realizing the incumbent's core logic was bad — not its design. Familiar UX plus a genuinely better engine is enough to displace.
“The tip number one for sure will be to validate before spending money on ads. And when I say validate, it's not just that the product works, but also that people are willing to pay for it.”
Validate willingness to pay before you spend a dollar on ads
Free signups and engagement are not proof of a viable subscription business. Validation has to include actual paying customers before any paid acquisition turns on — otherwise the ads are funding a leaky bucket disguised as growth.
“In terms of validation, I just build apps that solve my own problems… I will always be my first customer, and so I always know exactly what's needed in the product, what are the requirements, what works and what doesn't.”
Build apps that solve your own problems — be your own first customer
Skip elaborate validation rituals and build apps that solve your own problems. Being your own first customer removes the guesswork about requirements and feature priority — you always know what works because you're the one using it daily.
“In terms of finding good ideas, my recommendation is to just start building anything — it doesn't matter what exactly. Once you get into the groove and start building something, you will naturally get a ton of other great cool ideas for later projects.”
Just start building anything — better ideas surface once you're in the groove
Don't agonise over picking the perfect idea before you start. Once you're heads-down building something, better ideas for future projects naturally surface along the way. The first project rarely is the one — but it unlocks the next one.
“My way of doing things is just to actually build a product, or at least an MVP for it, and then share it to as many people as I can and get instant feedback from the users.”
Ship the MVP and let users guide the iteration — talking to people is the real roadmap
The fastest way to validate is to build a small MVP and put it in front of as many people as possible to get instant feedback. Focusing on a project for a short, finite amount of time forces clarity on whether it's actually valuable — and talking to users is how the real feature list gets built.
“As an indie hacker, as a bootstrapper, you can't create the next Uber, you can't create the next Facebook — you need a lot of money for that… You should approach a market which is already validated, and then just find the gap.”
Don't invent — enter a validated market and find the gap competitors leave open
Indie hackers can't fund category-creating moonshots. The winning move is to target a market already validated by big incumbents with paying users, then find a specific gap. Pricing alone is rarely enough — pair it with feature complaints users post publicly.
“Step one — you look for a popular tool and search social platforms like Twitter and Reddit with keywords like 'X alternative', where X is basically the product with lots of users.”
Search 'X alternative' on Twitter and Reddit to surface ready-to-switch buyers
A repeatable discovery method is searching Twitter and Reddit for 'X alternative' against tools with large user bases. The threads expose unmet needs and a ready-made audience already shopping for a switch — pre-qualified for whatever lands in that gap.
“Step three — reach out to those users with your solution, with just a basic landing page explaining your solution. So messaging is the key here.”
Reach out to the competitor's users with a landing page before writing any code
After identifying a popular tool and the unmet pain points around it, validate demand by DM'ing those users with a basic landing page describing the solution. No product is required yet — messaging is what determines whether they bite, and that proves intent before any code gets written.
“He was expecting I'll take maybe 3 or 4 days to complete the job. The whole 1,800 mockups got done under 30 minutes. The customer was stunned. He asked 'How did I do it?' I did not explain and I just said give me $300 and I'll give you this. And without giving any second thought the customer wired me $300.”
Charged $300 mid-job after one-shot proving the tool worked
Vikash validated demand by accepting a freelance gig (1,800 mockups in 3-4 days), secretly automating it in 30 minutes, then refusing to explain the trick unless the client paid $300 for the tool. The instant wire confirmed paying willingness before he ever built a real product — the gig itself was the validation test.
“We didn't do all four at once. It was 'Let's hop on a sales call. Let's talk about pop-ups. Let's say we're a pop-up tool and let's see what the close rate looks like.' I noticed very quickly on the calls they were shorter, they were more succinct, and they closed more often.”
Test new positioning live on sales calls before changing anything else
Before rebuilding the site or the content, Sean ran the new positioning as a live A/B test on sales calls and watched close rate, call length, and clarity. Only after calls converted better did he roll the message out to content, website, and internal language. Cheapest possible validation surface for a pivot.
“Free users don't actually validate your product — they will just consume it and if something doesn't work they will just ghost you. Paid customers, because they have put real money in, will tell you exactly what is broken.”
Paying customers give brutal feedback; free users ghost
Devin pushes back on 'just give it away for feedback' advice. Of his 250+ LTD buyers, only ~10% became active long-term users but those gave brutally honest, unfiltered feedback over Intercom — some even tracked down team members directly. Real money in the door buys you real signal back out.
“A few months ago I wanted to build my own mobile app and I paid a designer on Upwork for a decent design and it was hundreds of dollars. Every time I wanted to make a little change I had to pay him extra. I thought if I could build an AI tool around this I could save people a lot of time and money.”
Solve a problem you have paid out of pocket for — willingness to pay is already proven
Diego validated by living the pain himself — paying hundreds out of pocket for mobile app designs and getting nickel-and-dimed for every revision. Because he had already opened his own wallet for the problem, he skipped waitlists and interviews and went straight to building.