A list of SaaS ideas can keep you busy for a weekend without telling you what to build on Monday. The missing ingredient is evidence: someone has a recurring problem, has tried to solve it, and cares enough to change how they work. Start there before you choose a framework or design a subscription page.
This guide uses an illustrative example: a weekly client-reporting service for small agencies. It is a hypothetical business, not a customer case study. You can replace that workflow with your own and keep the same sequence of interviews, experiments, and decisions.
Turn the idea into a problem statement
Write down who does the work, what triggers it, what they do today, and what goes wrong. For our example: an agency account manager spends Friday gathering results from several sources, formatting a report, and asking colleagues to check it before sending it to a client. The product opportunity might be collecting data, catching mistakes, or getting approval. Those are different problems.
Avoid combining them in the first experiment. Pick the most costly step you can observe and describe what a better result would look like. Faster reporting is vague; a checked draft ready for the manager to approve is something a person can evaluate.
Interview people about the last real occurrence
Ask about the most recent report rather than whether they like your idea. Have them describe the steps, the tools they opened, and the moment they got stuck. If appropriate, ask to see a redacted example. Their current process tells you which constraints your product would inherit.
- When did you last do this, and what started the task?
- Which step needed the most checking or back-and-forth?
- What have you already tried to make it easier?
- Who approves a change to this workflow?
- What happens if the work is late or wrong?
Keep your notes separate from your interpretation. A quote about a frustrating export is evidence. Your conclusion that the customer needs a dashboard is a hypothesis. Mixing the two makes it too easy to turn every interview into support for the product you already wanted to build.
Use search interest to improve the questions
Search language can help you find the vocabulary people use. Compare a problem phrase, an existing solution, and a specific task in Google Trends. Keep the geography, time range, and search type consistent. A term that is useful for discovery may still be too broad to describe your buyer.
Google explains that Trends uses normalized search interest, rather than monthly search counts. A low value does not prove that a niche has no buyers. For a small B2B product, an interview with a person who controls the workflow can be more informative than a broad search spike.
Run a manual pilot before building automation
Offer to produce one report with the customer, using an agreed sample and a clearly stated process. Ask which parts require approval and what information should stay out of the experiment. Do not imply the service is automated if you are doing the work yourself.
Record how long each step takes, which assumptions fail, and how much checking the customer still needs to do. A manual pilot is a rehearsal: you want to discover the hard scene before you build the entire stage. If the customer needs many exceptions, narrowing the audience may help more than adding settings.
| Assumption | Small test | Evidence to keep |
|---|---|---|
| The task repeats | Ask about recent occurrences | Dates and actual examples |
| The result is useful | Deliver one reviewed sample | What the customer uses or rejects |
| The workflow can change | Agree a second pilot | Owner, timing, and next commitment |
| Automation helps | Repeat the manual process | Repeated steps and exceptions |
Decide what would make you continue or stop
Set a decision rule before you run the pilot. For example, continue only if the intended user uses the report and agrees to another cycle with the necessary data. This is a suggested experiment rule, not an industry benchmark or a promise of demand.
A compliment is weaker than an agreed next action. A pilot that nobody wants to repeat gives you useful information too. Ask whether the problem was unimportant, the output was wrong, or the effort to change was too high. Each answer suggests a different next experiment.
Translate the evidence into a small MVP
Write an MVP brief containing the user, the recurring trigger, the input, the output, and the acceptance check. For our example, start with one report type from one source. Keep approval manual if that is how the customer already works. Defer multi-team administration until someone needs it.
Use the no-code MVP guide to choose an implementation path, or the AI coding workflow if you plan to own the code. Browse IndieNew Tools once the experiment has told you what you need.
Key Takeaways
- Describe a recurring problem before choosing a SaaS idea.
- Interview people about recent behavior, not hypothetical enthusiasm.
- Treat search interest as a clue and a repeat pilot as stronger evidence.
- Write the continue-or-stop rule before you interpret the results.
Choose one workflow you can investigate this week, then use the IndieNew directory to find only the tools that experiment requires.