How 200+ Successful Founders Actually Found Their SaaS Ideas
Choosing the right SaaS idea can be the difference between making 10,000,10,000, 10,000,100,000, or even $1 million a month—and making nothing at all.
But I'm not here to give you another list of hypothetical SaaS ideas. That's not what you need.
What you really need is to know how successful founders actually found their idea—and how you can steal their tactics to find your own.
So here's what I did: I surveyed over 200 SaaS founders making at least 1,000amonth(somemakingwellover1,000 a month (some making well over 1,000amonth(somemakingwellover100,000 per month) to uncover the exact methods they used to find their winning ideas. I've seen these methods work in my own companies, across the hundreds of startups I've invested in, and throughout the broader TinySeed, MicroConf, and Startups for the Rest of Us ecosystem.
Here's what the data revealed:
Method % of Founders Find a problem at your day job 48% Scratch your own itch 16% Copy an existing product 10% Discover a problem through freelancing 10% Solve a problem for a spouse, friend, or colleague 8% Build on an existing product 4% Find a problem online 3% Emerging/fast-growing technology 3%
One number jumped out immediately: 72% of founders found their idea through their work—day job frustrations, expensive tools they knew they could build better, patterns from agency clients, or opportunities discovered while building something else.
Your next SaaS idea might already be right under your nose. But you need to know what to look for.
Method 1: Find a Problem at Your Day Job (48%)
Nearly half of successful founders found their idea at work. This makes sense—you're spending 40 hours a week immersed in problems, workarounds, and frustrations. You already have context, credibility, and access to potential customers.
This path shows up in a few different flavors.
The frustrated developer who's fed up with bad tools is the classic version. Alex Yumashev built Jitbit, a helpdesk ticketing system, after realizing that existing support apps were missing the "boring" features real teams actually need:
"Things like SSO, Active Directory integration, user provisioning, on-prem self-hosted deployment for Windows. The sleek, modern tools had none of that. And the ones that did have the boring features looked like they were straight out of the '90s—cluttered UIs, endless checkboxes, painfully complicated setup flows."
The subject matter expert who knows an industry's pain points inside and out is another common profile. Zach from Upstream Edge spent a decade as a petroleum engineer before building desktop software for forecasting and valuing oil and gas wells:
"My frustration with the current tools led me to learn how to build new tools to solve our daily problems. I had a burning desire to see better software, and I decided to make the product I thought the industry needed."
The observer who notices colleagues doing tedious, repetitive work is a third variation. Steve from Ludi (formerly Metro Retro) built collaboration software for development teams after watching a PM struggle:
"I created an early prototype of a canvas-based retro tool as part of a hackathon at my last real job. The idea came from watching the PM write up the notes after every meeting by hand."
Sometimes the observation happens years before you build anything. Lee Dydo built DYDOMITE, software for getting looping video on public screens, based on problems he noticed a full decade earlier while working at a digital signage company:
"It's a very hardware-focused industry, and I repeatedly kept seeing the same problems when it came to operational software. Nobody was thinking about user experience. I kept socking away my ideas until one day, 10 years later, I thought it was time to jump."
The consultant-turned-founder represents yet another variation. Ahmed Babikir co-founded BlueGamma, which provides interest rate forecasts for finance teams, after noticing a pattern from his consulting days:
"Clients would ask us for interest rate data, sometimes multiple times a day. As a recent graduate, my job was to pull the data, format it, and send it over in a spreadsheet every time. After leaving the company and learning about startups a year later, we realized it was a repetitive problem that software could solve very easily."
Why this method works so well: You've lived the problem. You know the workarounds. You understand why existing solutions fall short. You have built-in access to potential customers and beta testers through your colleagues and industry contacts. And you understand the buying process—who signs off on purchases, what budget cycles look like, what objections come up.
The risks to watch for: Make sure the problem exists beyond your specific company; your employer might just be uniquely dysfunctional. Check your employment agreement for IP clauses—some companies claim ownership of anything you build while employed. And be careful not to use proprietary information or customer data. If you're going to pursue this path, use your own laptop and keep things clean.
Method 2: Scratch Your Own Itch (16%)
This approach was popularized by Basecamp's Jason Fried and DHH in the early 2000s, and it remains a solid path—though not as dominant as the day-job method.
The key distinction: you're not just building for yourself. You're building something for yourself and then discovering that other people have the same problem and will pay for it.
Olga Heuser founded DialogShift, an AI application for hotels, after experiencing frustration as a guest:
"We came up with the idea as hotel guests ourselves, frustrated by how difficult it was to get simple information about what, where, and when things were happening during our stay. Our initial thought was, how great would it be to just send a WhatsApp message and instantly get answers to all our questions?"
Scott Brownlee built Simplebooklet after spending 11 years sailing around the world with his wife and struggling to access information about places they visited:
"Getting access to information was difficult and usually in the form of paper brochures, lookbooks, and guides. I really just wanted to scan a QR code or get it on my tablet or phone. Since every print brochure started as a PDF, how could we make that more accessible?"
A critical caveat: Having a problem yourself is not validation. It's validation that you'll have one customer paying you $0—yourself.
When I built Drip, it started as software to scratch our own itch. But before we committed to building it, I asked 17 other founders if they had the same problem. When 10 or 11 said yes, we started building. If you're going to scratch your own itch, validate that others share it before you invest serious time.
Why this method works: You understand the problem intimately. You're genuinely motivated to solve it. You can be your own first user, which speeds up iteration. And your passion often comes through in marketing and sales.
The risks to watch for: You might be a market of one. Your use case might be too specific to your situation. And it's easy to build what you want rather than what the market needs.
Method 3: Copy an Existing Product (10%)
"Copy" is a strong word. What this really means is entering an existing category with a clear differentiator—usually price, user experience, or focus on a specific niche.
Tim Leland built T.LY URL Shortener after seeing how much his employer was paying for Bitly:
"We looked at Bitly and saw it was thousands of dollars to use a custom domain to create short links. So, to save money, I built a simple in-house URL shortener over the weekend. This got me thinking other companies may want a more affordable option."
Lilia Tovbin built BigMailer, an email marketing platform, after her previous startup's email list grew to 300,000 subscribers and every available solution seemed overpriced.
This approach can also mean porting an existing product to a new geography. Simon Thompson built Hooroo.ai, an AI answering service for Australian businesses:
"I saw examples in the US doing the same thing and figured there would be a need for the same type of service but specifically with Australian accents and sensibilities. I also guessed that it wouldn't make sense for the major players in the US to go to market in Australia anytime soon."
When I built Drip, we entered an existing category—email automation—but positioned ourselves against expensive incumbents with annual contracts and clunky software. We didn't have to explain what we were. We just had to explain why we were better.
Why this works: You have proof of demand. You can learn from the incumbent's mistakes by reading their negative reviews. And if the market is large enough, even a small slice can be a great business.
Why it's hard: You need a real differentiator beyond "we're newer." The incumbent has a head start on brand recognition, SEO, integrations, and customer trust.
Method 4: Discover a Problem Through Freelancing or Agency Work (10%)
When you're building custom software for clients, you start to notice patterns. The same requests come up again and again. That repetition is signal.
Ben Walker built Drum, an ERP for small to medium consulting firms, after years of custom development work:
"I was consulting as a custom software developer and found that I was building very similar functionality over and over. I felt that if I could build a very basic version of what I was building my clients, but build it as a standalone tool, I should be able to find some early customers and iterate."
John Reynolds took an even more direct path with Civic Review, his permitting software for local government:
"I was a freelance software developer, and I was asked to build our product by municipalities. I was asked three times, and on the third time I decided, okay, these guys can't find a SaaS solution that fits their needs. I'll just make my own and sell it so I don't have to keep rewriting the same software."
Sometimes the opportunity isn't what clients ask you to build—it's a tool you need to run your agency more efficiently. Colin Bartlett built StatusGator, a status aggregator, after a frustrating day debugging:
"I was working on a bug ticket for a customer all day and finally came across the status page for the Facebook ads API—it had a warning about intermittent failures. Turns out that was the bug. It annoyed me that I didn't even know the status page existed. I thought it would be really nice to have all that on one screen and get an email when the status changed."
Important note on IP: Review your client contracts carefully. Joe Walling built Dump Truck Dispatcher for bulk hauling companies by negotiating wisely with an initial client: "I kept the IP in return for charging them less for the software."
Method 5: Solve a Problem for a Spouse, Friend, or Colleague (8%)
Sometimes the best opportunities come from people you already trust. This method gives you a direct line to someone experiencing the problem—instant access for interviews, feedback, and iteration.
Jon Sustar founded Quill Therapy Solutions, which generates documentation for mental health therapists, because of his wife:
"My wife is a therapist and she 100% thought of the idea. She saw me working on a different idea that relied on AI to rearrange information and she basically said, 'Hey, could you do that for progress notes instead?' And she was right."
Jói Sigurdsson built CrankWheel, a screen-sharing platform for sales, after brainstorming with his co-founder Gilsi, who had years of experience in phone and in-person sales:
"I innocently asked him at some point what people use when they're on the phone with a prospect and they need to show them something. As it turned out, they didn't use anything because it's too complex for a lot of prospects and you don't want to take a good sales call and ruin it with tech issues. That's how the idea for CrankWheel was born."
The risks to watch for: Your spouse or friend might have a unique problem others in their field don't share—so validate beyond them. And they might be too nice to tell you your solution isn't good. Push for honest feedback, and ask them to introduce you to others in their field.
Method 6: Build on an Existing Product (4%)
Sometimes you're already working on something and discover a bigger or better opportunity—an internal tool with outside demand, or an adjacent problem your customers keep mentioning.
Ivana built AuthoredUp, a LinkedIn content creation tool, while working on a completely different startup:
"We were working on a startup for hiring managers and recruiters. After we almost finished the product, we wanted to get feedback and beta users. We tried creating content on LinkedIn, but we couldn't find simple tools to help us out. That's when we built this internal tool."
Rafal built Supadata, an API for extracting data from platforms like YouTube and TikTok, after initially building a scraper for his own product:
"Over time, I also used this scraper to build other small products. It became de facto an API servicing multiple apps. At some point, I decided to make a small experiment and try to monetize it on RapidAPI. From there, it snowballed."
The risk: Make sure you're running toward a real opportunity, not away from hard problems in your current product.
Method 7: Find a Problem Online (3%)
This method gets talked about a lot, but only 3% of successful founders actually used it. The signal-to-noise ratio is low, and you lack the insider context that makes other methods more reliable.
That said, it can work. Tolu Akinola built StreamThing, a Shopify app for selecting delivery dates, by systematically mining the Shopify support forums:
"I combed through the Shopify support forums to find issues that merchants were complaining about. I prioritized issues that had apps with lots of reviews, but also a lot of negative reviews. This helped identify problems that were pervasive but not well addressed."
Ramy Khuffash combined hypothesis-driven exploration with keyword research to build Hovercode, a dynamic QR code generator:
"I did some keyword research with Ahrefs to see if there was demand for QR code tools and saw huge search volume, which was enough for me to get involved in the space."
If you try this approach, look at Reddit communities for specific industries, Facebook groups for niche professionals, support forums for existing products, review sites like G2 and Capterra, and keyword research tools.
Method 8: Emerging or Fast-Growing Technology (3%)
Every developer dreams of spotting a new technology early and building on it before the market gets crowded. But only 3% of successful founders actually pulled this off.
Ram Shengale built WANotifier, a WhatsApp marketing tool, by timing his entry with WhatsApp opening up their API:
"Right around 2022 when I was looking for SaaS ideas, WhatsApp opened up their gates for new API partners. So the timing was right."
Thiago built Podsqueeze, an all-in-one podcast production tool, right after ChatGPT launched:
"I got really frustrated with all the post-production work—creating show notes, promotional content. ChatGPT had just been released, and we thought that even if the AI transcripts made mistakes, GPT was smart enough to generate good text assets."
Why it's hard: Timing is brutal. Too early and the technology isn't ready. Too late and you're one of hundreds of competitors. And big players can move fast in hot spaces.
A Framework for Evaluating Any Idea
Regardless of which method resonates with you, run any potential idea through these questions.
On the problem: What tools frustrate me or my co-workers on a daily basis? What manual processes exist that should be automated by software? Are the incumbent tools actually old and clunky, or do I just not like them?
On validation: How many other people have this exact problem? Can I find them and talk to them? Would people pay money to solve this, or do they just want to vent? Am I a representative user, or am I an edge case?
On competition: Why are customers unhappy with current options—price, features, support, usability? Is my differentiation something customers actually care about? Can I reach customers through a channel the incumbent isn't using well?
On your fit: Do I have the patience to learn an unfamiliar industry? Am I willing to invest time deeply understanding the market before building? Am I building this to solve a real problem, or because it seems interesting?
The Takeaway
Seventy-two percent of successful founders found their idea through their work. The SaaS opportunity you're looking for might already be in your daily routine—the clunky tool you complain about, the manual process you wish was automated, the expensive software you know could be built better.
The difference between founders who find great ideas and those who keep searching isn't luck. It's knowing what to look for.
[CTA BOX]
Find the SaaS Idea Hiding in Your Workday
We created the 9-to-5 Audit to help you systematically uncover opportunities in your current job. It includes additional founder examples we couldn't fit in this post, plus thought exercises to help you discover what you might be missing.
[Get the free audit at robwalling.com/ideas]
This research will also appear in my upcoming book on finding, validating, and launching a profitable SaaS business. For early chapter previews and launch updates, join my email list at robwalling.com/emails.
