SaaS idea validation is not a score from an AI tool or a checklist of boxes to tick. It's two separate questions, answered in order: does this market actually support a business, and is there a specific angle only you'd think to build. Most validation advice only answers the first one.

That gap matters more than it sounds. A March 2026 CB Insights analysis of 431 VC-backed companies that shut down since 2023 found poor product-market fit was the second most common failure cause, 43%, right behind running out of capital. That's VC-backed data, not bootstrapped indie data specifically, but the pattern holds either way: a lot of failure gets decided before anyone writes a line of code, not after.

Why "does this solve a real problem" isn't the actual question

Almost every idea-validation guide stops at "is there a real problem here." That's necessary, but it's not sufficient, and treating it as the finish line is why so much validation advice produces confident founders building into markets that can't actually support them.

Two things predict whether a market can support a business: proven demand (people are already paying to solve this somehow, even badly) and room for a genuinely differentiated angle, not just the same product with a nicer interface. Derrick Reimer sold the email platform Drip in 2016 and later built the scheduling tool SavvyCal. He's described spending months deliberately auditing SaaS markets for exactly these two signals before writing any code. His read on it: most indie hacker failures he's watched were market failures, not product failures, cases where the builder did everything right inside a market that couldn't support the business.

That's the part checklist-style validation tools skip. A market can pass every demand test and still be the wrong one, because passing the demand test only tells you a business is possible there, not that yours is the business worth building.

The signal that doesn't show up in market research

Demand and competition data tell you where a market can support a business. They don't tell you what to build inside it, and that's the part a spreadsheet can't hand you.

The angle usually comes from something closer to observation than analysis, a specific, felt frustration with how the existing options work, not a gap you spot in a competitor matrix. Take Reimer's account of SavvyCal as an example, not because the product itself matters here, but because of where the idea came from. His market-level research told him scheduling had proven demand and recurring revenue. The wedge itself, a scheduling tool that made booking feel less one-sided for the person on the receiving end, came from noticing an everyday annoyance, not from a spreadsheet.

That's the piece worth internalizing separately from the market-selection process: market research narrows the field to markets worth entering. It doesn't pick the specific thing worth building once you're in one. That second part comes from paying attention to what genuinely bothers you or the people around you about how something currently works.

What this looks like for a solo developer or a two-person team

Most idea-validation content assumes either a non-technical first-time founder with no product to point at yet, or a team with a research budget. Neither describes a developer who already knows how to build and is choosing what to build next. That's the actual, recurring decision point for anyone shipping solo or in a small team.

Scoped for that reality, this isn't a multi-month research program. It's closer to a focused week or two before committing:

• Check whether people are already paying to solve this problem somehow, even through a clunky workaround, a spreadsheet, or a competitor you think is mediocre. No paying behavior at all is a real warning sign, not a gap to fill.
• Name the specific angle you'd bring that the existing options don't, in one sentence. If you can't state it in one sentence, it's not sharp enough yet.
• Write down the actual frustration that made you notice this problem in the first place. If there isn't one, and the idea only sounds appealing in the abstract, that's worth treating as a signal on its own.

Picture a developer who's shipped one small utility app and is deciding what to build next. Spending that week reading competitor pricing pages, reviews, and complaint threads costs almost nothing next to the months a wrong build would cost. Skipping it because the idea feels exciting is the expensive version of validation, paid for later, in wasted build time.

Competing against a free incumbent, and why that's not always a red flag

A common instinct is to treat any market with a strong free option as closed. That instinct is wrong often enough to be worth naming directly.

Every scheduling tool competes against a free tier bundled into nearly every productivity suite. Reimer has been candid that this shaped nearly every decision for SavvyCal: pricing, positioning, and eventually a second, higher-priced product for buyers who can't use the free option at all. A market with a credible free competitor forces pricing and positioning discipline from day one. "Why wouldn't I just use the free thing" is a real objection, and you have to answer it before a single paying customer shows up.

Compare that to a market with zero competition and zero proof anyone pays for anything close to your idea. The free-incumbent market has already answered the demand question for you. The empty market hasn't, and "nobody's building this" is at least as often a sign that nobody wants it as it is an open opportunity.

The reframe worth sitting with: the scarce skill for a developer who can already build isn't the ability to build. It's judgment about what's worth pointing that ability at, and that judgment comes from checking demand and competition with a clear eye, then trusting a specific, felt frustration over a generic idea that only sounds good in the abstract.