Finding a SaaS idea is a search problem, not a creative one. Spend a week reading places where paid problems are already documented — one-star reviews of tools people buy, job postings describing manual work, and community threads asking for software that does not exist — then generate candidates against your own domain advantage and reject them fast on four criteria: a reachable buyer, existing spend, a scope you can build alone, and no incumbent serving that segment well. Expect to reject twenty ideas to keep one. The rejection rate is the procedure working, not failing.
Before you look at a single idea, write two sentences: what you know that most people do not, and who you can reach this week without an introduction.
This is not a warm-up. It is the filter that makes the rest of the week productive. An idea that hangs off eight years in dental practice admin is testable on Monday, because you already have the phone numbers and the vocabulary. The identical idea handed to an outsider is a three-month research project before the first useful conversation.
If you genuinely have no domain advantage, your first move is not idea generation — it is picking a reachable audience and spending two weeks inside their forums until you have one. Founders skip this and then wonder why every idea feels equally plausible: without an advantage, they are.
Give this two days. You are collecting complaints, not ideas.
Write each complaint down verbatim. Those sentences become your landing page copy later — phrased by the buyer, which is better than anything you would compose.
Now turn the raw complaints into shaped candidates. The generator below takes what you wrote in step one and returns four ideas that each name a buyer, an existing workaround, where to verify the demand, the specific catch, and a test that costs under $100.
Run it more than once with different framings of your advantage — "I know practice managers" produces a different list from "I know how practice management software fails". Two or three runs across an afternoon gives you a candidate pool of eight to twelve.
Do not evaluate while generating. Collect first, judge in the next step. Judging as you go is how founders end up with four variations of the idea they already secretly wanted to build.
An industry you worked in, a tool you know inside out, a group you have access to. Vague in, vague out.
Every candidate faces the same four questions, and most die on the first or second:
Aim to reject twenty candidates to keep one. Speed here is the whole value — five minutes of honest filtering saves three months of hopeful building.
One candidate now gets a week of real contact. Find five people who match the buyer description and ask about their process — never about your idea.
Three questions carry it: how do you handle this today, what happened the last time it went wrong, and what have you already tried to fix it? The third is the most valuable. Someone who has already bought and abandoned two tools has a budget-bearing problem and a list of reasons those tools failed.
You are listening for one thing: do they describe your problem in their own words, unprompted? Five of five is rare. Three of five is a real signal. One of five means you found something that interests you more than it bothers them.
End the week with one idea and one dated test — not a repository.
The test should cost under $100 and produce a yes or no inside seven days: a priced landing page with a deposit button, forty personalised outreach messages, or doing the job manually for one paying customer. Write the pass mark before you run it ("five deposits or I stop"), because a threshold set afterwards is not a threshold.
Then put the idea through a verdict tool for a second opinion before you spend the week. Triage is cheap; a quarter is not. If the test fails, you still have eleven candidates in the pool and one week gone instead of one quarter.
kitty.build runs the researched version of this: nine specialist boards take a candidate idea, search the live web for who already sells it and what their customers complain about, and return a cited GO / PIVOT / NO-GO before you write a line of code.
Feed her an idea