Why do so many indie projects fail? In a word: demand. The #1 killer of indie startups is building something nobody really needs. You might crank out a brilliant app, but if it doesn’t scratch a real itch for someone, it’s doomed. In this guide, we’ll flip the script and learn from 35 indie hackers who uncovered pain points people actually care about – and turned those insights into profitable products.
We’ll start with a quick overview of all 35 founders, their products, revenue, and core niche-finding insight. Then we’ll dive into five proven “playbooks” for need-finding, peppered with quote cards from each founder (feel free to download or print them!). Finally, we’ll wrap up with a 6-step need-mining framework and a handy checklist + toolkit to start unearthing lucrative niches of your own. Let’s go! 🚀
Meet the 35 Founders: Niche, Product, MRR, Insight
Here’s a whirlwind summary of 35 indie founders who discovered profitable problems to solve:
- Pieter Levels (Nomad List) – ~$40k MRR – Solved his own digital nomad problems, which turned out lots of others had too.
- Arvid Kahl (FeedbackPanda) – $55k MRR at exit – Embedded himself in an online teachers community to find a painful workflow to fix.
- Jon Yongfook (Bannerbear) – ~$50k MRR – Tried many ideas; when one showed traction, he doubled down, guided by user feedback.
- Tony Dinh (Black Magic etc.) – ~$45k MRR – Launched fast and iterated based on real user behavior (e.g. Twitter power-user tools).
- Thibault Louis-Lucas (TweetHunter) – ~$20k MRR (pre-acquisition) – Built an add-on for an under-served platform (Twitter) and rode its growth.
- Courtland Allen (Indie Hackers) – N/A (community acquired by Stripe) – Scratched his own itch to connect founders, launched quickly, and iterated with user input.
- Cory Zue (SaaS Pegasus) – ~$8k MRR – Leveraged domain expertise (Django devs) – chose a niche where he had an “unfair advantage.”
- Raymond Yeh (Wisp) – Sustainable small SaaS – Picked a problem space he was passionate about (headless CMS) and stuck through slow early growth.
- Qayyum Rajan (Lancr) – Multiple exits – Targeted “boring” offline industries that lacked modern software (where big players weren’t looking).
- Marc Louvion (ShipFast, etc.) – ~$50k/mo sales – Made multiple small bets: launched dozens of tiny products cheaply, then focused on the few hits.
- Alex West (CyberLeads) – ~$42k MRR – Failed 19 times until one idea hit – a B2B lead list – then learned from those failures to refine the winner.
- Bhanu Teja (SiteGPT) – $15k MRR – Capitalized quickly on a new tech trend (GPT-3) to offer AI Q&A for websites.
- Andrey Azimov (Sheet2Site) – $10k MRR (sold) – Shared his journey in public and solved a niche problem he personally faced (websites from Google Sheets).
- Guillaume “Rox” Pacheco (ThumbnailTest) – 6-figure exit – Built a one-feature “plugin” for YouTube (A/B testing thumbnails) that the platform neglected.
- Sebastian Röhl (Indie Apps) – $30k MRR – Focused on niche mobile app categories (e.g. habit tracking) and kept improving based on App Store feedback.
- Maciej Cupiał (Calendesk) – $26k MRR – Noticed a painfully clear problem (SMBs struggling to schedule customers) and charged from day one for his solution.
- David Bressler (FormulaBot) – ~$40k MRR – Applied AI to a specific everyday struggle (writing Excel formulas); proved even a solo indie can win in a huge market by nailing a niche use-case.
- Dawson Botsford (Earnifi) – ~$100k MRR – Launched an extremely scrappy prototype in the crypto space (unclaimed airdrops) and iterated only after real demand showed up.
- Nicolai Klemke (Neural Frames) – $17k MRR – Turned deep domain expertise (physics + AI) into a unique offering (AI music videos), pricing it for a very specific creative niche.
- Rob Walling (Drip) – ~$166k MRR (at sale) – Started with a tiny, narrow-scope product (email marketing for micro-businesses), made it profitable, then “stepped up” to larger opportunities.
- Patrick McKenzie (Appointment Reminder) – ~$5k MRR (est.) – Literally talked to customers (small businesses) to uncover their painful scheduling problems, and explained his product in plain, non-techie language.
- Sahil Lavingia (Gumroad) – ~$1.7M MRR – Built a simple tool for creators, but crucially started by building a community around the “small and sustainable” business ethos.
- Justin Jackson (Transistor) – ~$100k MRR – Didn’t “build an audience” first – instead he helped one person at a time (podcasters) and let a loyal customer base grow organically.
- Amy Hoy (Freckle/Hexjaw) – ~$50k MRR – Went out “in the wild” to observe how people actually work, discovering they’ll happily pay for something they already want (not for something you have to convince them to want).
- Jason Fried (Basecamp) – ~$2M MRR – Intentionally underdid the competition: picked a narrower feature set (simple project management) he needed himself, and dominated that niche with quality instead of bloat.
- DHH (David Heinemeier Hansson) (HEY/Basecamp) – $2M+ MRR – Embraces being “small by design,” focusing on a tight niche and caring deeply about every customer rather than chasing unicorn growth.
- Lenny Rachitsky (Lenny’s Newsletter) – ~$166k MRR – Turned his product management knowledge into a paid newsletter by first delivering tons of value for free in the community, then iterating content based on subscriber feedback.
- Kevin Kelly (1000 True Fans) – Concept – Proved you don’t need millions of customers; 1,000 true fans can be enough to make a living. This principle guides many indie hackers to focus on niche audiences.
- Paul Graham (Viaweb/Y Combinator) – Concept – Advises “make something people want” and to do things that don’t scale initially (like personally onboarding users) to ensure you’re solving a real problem before automating.
- Steve Blank (Customer Dev Guru) – Concept – Pioneered “get out of the building” – you must talk to real customers in their environment and test all your assumptions before writing a ton of code.
- Eric Ries (Lean Startup) – Concept – Emphasizes starting with an MVP – the smallest thing that delivers value – so you can learn what customers actually want with minimal wasted effort.
- Marty Cagan (SVPG) – Concept – Urges founders to tackle the biggest risk first: value. Will anyone want this? Figure out the right thing to build (through discovery with users) before perfecting the build itself.
- April Dunford (Positioning Expert) – Concept – Preaches smart positioning: if you can’t beat big competitors at their game, change the game – redefine your product’s category/niche so that you’re the leader by default.
- Dru Riley (Trends.vc) – ~$40k MRR – Built a business on spotting emerging trends. He shows that being early (micro-SaaS, community-as-a-service, etc.) and curating insights can itself be a profitable niche.
- Noah Kagan (AppSumo) – ~$6.7M MRR – Motto: “Validate, validate, validate.” He won’t build anything unless 3 customers have pre-paid. He also hustled early on by going where his customers hung out (forums, meetups) and pitching them directly.
Whew! 😅 Notice some patterns? Let’s break these down into five key need-finding playbooks.
1. Scratch Your Own Itch
The simplest place to find a great idea: look in the mirror. Many founders started by solving a problem they personally had, knowing that if they needed it, others might too. The key is making sure it’s not only you who has that pain! Here are a few who nailed the “scratch your own itch” approach:
Pieter Levels launched Nomad List as a scrappy spreadsheet to rank cities for digital nomads – essentially building a tool for himself. Turns out thousands of remote workers wanted that info, validating his own itch on a larger scale. By solving his own nomad problems (finding WiFi, cost of living, etc.), he struck a nerve with a whole niche audience of globetrotting techies.
Building something for yourself means you’re likely passionate about it – a huge plus, because early growth can be slow. Raymond Yeh spent months working on a headless CMS (far from an overnight success), but because he cared about the problem and used the tool himself, he pushed through the quiet days until it found traction.
Other founders like Courtland Allen (Indie Hackers) and Jason Fried (Basecamp) also started with their own needs. Courtland wanted a community of indie founders, so he created one. Jason needed a simpler way for his design team to manage projects – Basecamp was born. The advantage of scratching your itch is you deeply understand the problem. Just be sure others share your itch (don’t build the ultra-niche “just-for-you” tool). When done right, solving a personal pain can attract a tribe of people just like you who say “OMG, I need this too!”
2. Embed in an Audience
What if you don’t have a personal burning problem? Then go embed yourself in a community of potential customers and watch/listen to them. Indie hackers who do this become problem sponges – soaking up frustrations from real people and then building solutions.
Justin Jackson famously advises new founders to “just help one person.” He hung out in podcasting forums and Slack groups, answering folks’ questions and noting their struggles. That led to Transistor (podcast hosting) almost organically – by the time he built it, he knew lots of people needed it, because he’d basically been their unofficial support group already!
Patrick McKenzie (aka patio11) literally cold-called and visited local businesses to learn their pain points. He discovered dentists and salons drowning in no-shows and phone tag. By embedding himself in their world (even though he’s a developer, not a dentist!), he uncovered a hair-on-fire problem. Crucially, Patrick also learned to speak their language – pitching Appointment Reminder not as “robust twilio SMS integration” (tech jargon), but “we’ll reduce your no-shows”. He got customers by understanding and using the voice of the customer.
Arvid Kahl (FeedbackPanda) is another great example. He and his partner were online ESL teachers – a tight-knit community. Instead of coding in isolation, Arvid hung out where teachers gathered (Facebook groups, forums) and kept seeing the same complaint: writing student progress reports sucked up hours. That was the genesis of his SaaS – he literally co-developed the solution with input from that audience at every step. By launch, he already had fans eagerly waiting (since they felt the pain too).
The embedded approach means spending time in target-user communities: subreddit, Discord, LinkedIn group, niche forum, wherever. Watch for the repetitive “ugh, I hate doing X” or “Does anyone know a tool for Y?” posts – those are golden. Ask questions; even do 1:1 calls if possible. This isn’t fast work, but it massively de-risks your idea. You’ll end up building with your audience, not for a vacuum.
Oh, and remember to be a genuine community member – don’t just parachute in to mine them for ideas and vanish. Indie hacker success often comes from being one of the tribe. Help others, share knowledge, and you’ll naturally discover problems worth solving (and people will trust you to solve them).
3. Ride an Under-Served Platform
This playbook is all about piggybacking on a big platform’s growth – especially if that platform is neglecting a segment of users. The idea: find a booming ecosystem and build the missing tools/add-ons that power users of that ecosystem are craving.
Thibault Louis-Lucas (Tibo) did exactly this with TweetHunter. Twitter was (and is) huge, but lacked serious “pro” features for power users. Tibo noticed Twitter creators manually doing things like finding content ideas and engaging followers. So he built a SaaS to supercharge those tasks. By riding Twitter’s wave – and essentially offering what Twitter itself wouldn’t – he accessed a built-in base of thirsty customers (social media marketers, founders building in public, etc.). Eventually TweetHunter was acquired for 7-figures, proving the value of a bolt-on solution for an under-served platform audience.
Guillaume “Rox” Pacheco did something similar for YouTube. Power users on YouTube wanted to A/B test their video thumbnails (since that dramatically affects views). YouTube didn’t offer this (they were busy with mainstream features). So Rox built ThumbnailTest as a lightweight tool to do thumbnail experiments. He basically created a mini “plugin” business on top of YouTube. It solved a real need for serious YouTubers, and because it was tightly coupled with an existing platform, marketing was straightforward – hang out where YouTubers hang out!
The playbook doesn’t only apply to social networks. Rob Walling often talks about “tiny SEO apps” – he started with a simple JavaScript snippet for bloggers (an under-served niche by Google’s products at the time). Others build browser extensions for popular web apps, plugins for Notion, add-ons for Shopify, you name it. Look for fast-growing platforms (especially new ones) that have an ecosystem but not all the bells and whistles. If that platform’s users are trying to hack together solutions or repeatedly requesting a feature, that’s your cue.
One caution: platform changes can kill your addon (APIs get shut off, etc.). So, ride the platform but don’t be totally dependent on it forever – get users on your own mailing list, etc. Still, as an indie hacker, piggybacking on a giant’s growth (while offering what they don’t) can be hugely amplifying. Just ask all the folks who built Twitter client apps, Shopify plugins, WordPress themes… It’s a tried-and-true path.
4. Exploit “Boring” Markets
Not every profitable niche is sexy. In fact, many of the best opportunities are in so-called “boring” or under-the-radar industries where tech innovation lags. These are areas big VC-backed startups often ignore (not “cool” or “scalable” enough), which is exactly why indie hackers can thrive there without brutal competition.
Qayyum Rajan is a serial founder who explicitly seeks out boring markets. One of his companies, Lancr, provided online tools for freelance accountants and bookkeepers. Not exactly riding the VR/AI hype train – and that’s the point. By serving a market that isn’t in TechCrunch headlines, he faced less competition and could bootstrap sustainably. SMB accounting, lawn care scheduling, church volunteer management – these kinds of niches may not wow Silicon Valley, but they do represent real businesses with real pains (and $$ to pay if you solve them).
Marc Louvion launched 20+ mini-products in 3 years – ranging from a streak-tracking app to a Product Hunt analytics tool. Many of these were aimed at mundane problems or underserved micro-markets. His approach was to test lots of small ideas cheaply (especially in dull areas others overlooked) and see what sticks. One of his successes, ShipFast, is basically a boilerplate to launch startups quickly – a “boring” meta-product that happened to hit a need for other indie makers. By spreading bets across boring niches, he increased his odds that one would quietly turn into a cash cow.
Another champion of boring is Patrick McKenzie again – he has an essay actually encouraging targeting niches like “field service businesses” or “appointment-based businesses” because they have clear ROI from software. Big corps often ignore, say, a family-run plumbing business as a SaaS target – but if you can make that plumber’s life easier, they’ll gladly pay $50/mo for your app. Multiply that by thousands of similar SMEs and you have a hefty business – all while flying under competitors’ radar.
So don’t be afraid of boring! Embrace your inner plumber/carpenter/accountant mindset. These markets tend to have simpler requirements (you can build an MVP in weeks), yet they have real problems that software can solve. Your indie hacker superpower is being willing to serve markets that flashy startups won’t. As Noah Kagan often says, “there’s gold in the niches.”
5. Catch Early Trends
Our final playbook is the opposite of boring: it’s chasing shiny new trends. This is high-risk, high-reward territory. The idea is to spot an emerging technology or cultural shift very early, and stake a claim before the space is crowded.
Bhanu Teja did this with SiteGPT. In late 2022 when GPT-3 was just blowing up, he whipped up a weekend project to create chatbots powered by a website’s content. He effectively rode the AI wave right at the crest. Because he was so early (one of the first to productize GPT for website Q&As), SiteGPT attracted $10k MRR in just one month. Plenty of copycats followed, but by then Bhanu had loyal customers and a growing product.
Dru Riley built Trends.vc as a newsletter to literally identify trends for others. His business itself is powered by the meta-trend of people paying for curated insights. By the time many folks hear about a new tech (NFTs? no-code? Web3 communities?), Dru’s already published a report on it. His success comes from consistently being ahead of the curve. Subscribers pay because they know he’ll alert them to what’s next.
Being a trend catcher means you have to live on the frontier: always learning about new platforms, APIs, fads, etc. Paul Graham calls it living in the future and building what seems missing. Indie hackers Andrey Azimov and David Bressler did this with tech waves (No-code and AI respectively). They weren’t inventing new tech – they just saw the wave early and positioned themselves to surf it (e.g. Andrey’s Sheet2Site rode no-code website building before Webflow was a thing).
Caution: Trend-based products can be a rollercoaster. Today’s hot tech could fizzle next year. So, if you catch a trend, milk it but be ready to pivot or jump to the next if needed. Also, validate that the trend has business value, not just buzz. (Three different “AI for X” tools might all sound cool; the one that actually solves a painful problem will win).
In short, keep your ear to the ground. If you find yourself saying “hmm, not many solutions out yet for XYZ new tech, but people seem to want one,” you might have a trend-driven opportunity. Just move fast – by definition, the window won’t stay open long. As an indie hacker, agility is your advantage over big companies here.
Those are the five niche-finding playbooks! Many founders blend more than one of these (e.g. scratching their own itch and riding a platform, or embedding in a community and targeting a boring market). You can mix and match – there’s no rigid formula. The goal is to open your eyes to problems and validate that a group of people really needs a solution.
To bring it all together, here’s a simple 6-step framework to systematically mine for needs.
The 6-Step Need-Mining Framework
- Immerse Yourself – Dive into communities related to industries or hobbies you know (or are curious about). Read forums, join Slack groups, go where folks rant or ask for help. (Examples: Indie Hackers, subreddits, Facebook groups, product review comments).
- Listen for Pain – Within these spaces, specifically note complaints, tedious tasks people mention, or “😩 is there a better way to do ____?” posts. If you feel bold, ask “What’s your biggest headache with ____?” and listen. The key is spotting recurring pains.
- Quantify the Pain – When you see a potential problem, ask: how are they solving it now? How often does this occur? Does it cost them time/money/opportunity? A pain that’s frequent and costly is a high-priority problem to solve (and charge for).
- Draft Solution Concepts – For a top pain point, sketch a no-code mockup or workflow of how you might solve it. Don’t deep dive into tech – just outline the core of a solution. Share this concept back with a few target folks if you can and gauge their reaction.
- Pre-Validate Demand – Before building, try to get commitment from at least a handful of people. This could be as strong as pre-sales (Noah Kagan’s rule: 3 pre-paid customers or bust), or simpler like collecting emails via a coming-soon page or a forum poll “Would you pay $X for a tool that does Y?”. If you can’t get any bites, revisit steps 1–3 or try a different problem.
- Build an MVP (with Users) – Now that you have evidence of demand, build the scrappiest version of the solution that people will pay for. Keep your early adopters in the loop – even involve them in testing. Their feedback will ensure you’re on the right track.
- Pro tip: Don’t overbuild. Ship that V1 quickly, even if it only does one or two things. You can always add features with user input later (think of Eric Ries’s MVP ethos: learn from real users fast).
After launching your MVP, the cycle continues: immerse, listen, iterate. You’ll refine the product to better fit the need, uncover adjacent needs, and maybe even identify your next product opportunity from customer conversations. This framework is basically applying the scientific method to idea discovery – instead of guessing, you’re researching and testing at every step.
The Indie Hacker’s Need-Mining Checklist ✅
Before you rush off to code, run through this quick checklist (print it out or save it as your sanity-check cheat sheet):
- Have I observed or experienced the problem personally? (If not, have I spoken directly to those who have?)
- Did I confirm this problem is not a one-off? (Multiple people, independently, are complaining about it.)
- Is the pain significant enough that people know it’s a pain? (Nice-to-haves are harder to sell. We want hair-on-fire problems or at least “ugh, this sucks” level annoyance.)
- Who exactly has this problem? (Define your niche audience as clearly as possible – e.g. “independent accountants with 1-5 employees,” not just “small businesses.”)
- Where can I find more of these people to talk to? (List forums, communities, or personal contacts.)
- Have I floated the idea of a solution and gotten genuine enthusiasm? (People saying “I’d pay for that!” or “Please build this” are green lights.)
- Did I identify existing solutions/workarounds? (Know your “competition,” even if it’s Excel or hiring interns. Why is your approach better?)
- Am I avoiding feature bloat for MVP? (Solve the core problem first, delight a small user base, then expand.)
- Do I have a way to reach initial users cheaply? (Being embedded in the community or riding a platform wave often provides this. You shouldn’t rely solely on expensive ads at start.)
- Gut check: Does this idea excite me? (You don’t have to be your own customer, but you’ll be grinding on this for a while – some level of interest or passion will help keep you motivated.)
Toolkit of useful resources to help in this journey:
- Communities: Indie Hackers, subreddits like r/SideProject, r/EntrepreneurRideAlong, r/SaaS, Makerlog, and niche industry forums (for whatever market you’re exploring).
- Research Tools: Use Google Trends to gauge interest in problem keywords, AnswerThePublic to see common questions people ask on the topic, and Twitter search for complaints (try searching “[keyword] sucks” or “[keyword] need help”).
- No-Code MVP: If you want to validate super fast, tools like Zapier, Airtable, Typeform, or Bubble can let you create a “software” solution without writing code, just to test demand. For example, set up a Typeform that manually emails a solution to test if people will use it. It’s not scalable – and that’s fine for step 1.
- Pre-Sales & Feedback: Try a simple landing page using Carrd or LandingPage.new describing your idea and a CTA (“Request access” or “Pre-order at 50% off”). Share it in relevant communities (where you’ve earned trust) for feedback. This is low-risk way to see if strangers care.
- Books: The Mom Test by Rob Fitzpatrick (on how to talk to customers so you get the truth, not just polite “sounds cool” fluff), Obviously Awesome by April Dunford (on positioning your product in a unique way – great for boring markets or crowded ones), The Embedded Entrepreneur by Arvid Kahl (step-by-step on immersing in an audience before building).
Feel free to tweak this checklist and toolkit to suit your process. The main idea is to stay user-focused and evidence-driven in choosing what to build. It’s insanely easy to chase a whimsical idea down a code rabbit-hole (I’ve been there 🙋♂️) only to realize too late that nobody actually needed it. A little upfront need-mining can save you months – or even reveal a tweak that turns a mediocre idea into a killer one.
Final Thoughts: Build What People Want (Start Small, Learn Fast)
Ideas are everywhere once you train yourself to look for problems. As we’ve seen through these 35 stories, there’s no single “right” way to uncover a lucrative niche – you might stumble on it by scratching your own itch, or by carefully observing a community, or by opportunistically pouncing on a trend. However, all these approaches share a common thread: they start with real people and real problems.
Demand-first product development flips the usual script. Instead of “I built this cool thing, now how do I convince people to want it?”, you say “I found something people want – now I’ll build it.” When you operate this way, you’ll find marketing is easier (sometimes the product almost markets itself in niche circles), customer happiness is higher (because you’re solving an actual pain), and you can charge more confidently (because you provide clear value).
In the indie hacker journey, solving a real need trumps any growth hack or flashy feature. So keep need-finding at the heart of your process. Be relentlessly curious. When you hear someone gripe “ugh, this task takes forever,” perk your ears up! That’s your invite to explore.
Most importantly, take action. It’s one thing to nod along with this guide, and another to go out and actually interview a potential customer or post a mockup in a forum for feedback. So, pick one tactic from the playbooks or steps above and do it this week. Maybe schedule a 20-minute call with a friend who has domain expertise in an area you’re eyeing. Or lurk in a Facebook group and write down 5 pain points you see. Small steps like that can snowball into your next big idea.
Remember, every thriving indie product – no matter how humble – started by answering the question: “What do people need?” Keep asking that, keep observing, and you’ll be on your way to uncovering a profitable niche you can serve. Happy need-mining, and can’t wait to see what you discover! 🚀