How to validate a micro-SaaS idea before you build

1. Write a testable bet

A micro-SaaS is a narrowly focused software business, often built by a small team. Its small scope does not remove the need for demand. Begin by naming the person who experiences the problem, the person who can authorize payment, and the task you would improve.

“An AI tool for small businesses” is too broad to test. “A reminder tool for independent repair shops that lose track of unapproved estimates” gives you a buyer and a workflow to investigate. This repair-shop example is hypothetical; it is not a researched opportunity or a recommendation to build.

Choose the assumption most likely to break the idea. It might be that the problem is infrequent, that an existing product already handles it, or that the user cannot buy software. Write down what evidence would make you pause, revise the buyer, or stop. Set a time and spending limit for the investigation.

2. Research the existing problem

Look at current alternatives, published pricing, product documentation, and customer accounts of the workflow. Include spreadsheets, manual follow-up, and doing nothing. The question is how people solve this problem today, not just whether another company has your exact feature.

Keep a compact evidence log: the claim, source URL, date, buyer context, and what the source actually supports. Distinguish a vendor promise from demonstrated customer behavior. Several articles repeating one announcement are one underlying signal, not independent confirmation.

Record contrary evidence beside positive evidence. An old complaint may describe an issue the competitor has fixed. A frustrated reviewer may belong to a different segment. Public research can justify a buyer conversation; it cannot establish that your specific offer will sell.

3. Talk to qualified buyers

Recruit people who do the work or own the budget. Ask about a recent occurrence, the steps involved, the consequences, and what they have already tried. Avoid leading with a demo: agreement with your pitch can hide the fact that the problem was never a priority.

For the repair-shop example, ask how the last unapproved estimate was handled. Who followed up? What was delayed? Does the existing shop software include reminders? A story of an actual incident is more useful than “that sounds helpful.” Use the customer interview guide to structure the conversation.

Keep the denominator visible when reviewing results. “Three buyers described the same problem” means something different if you interviewed four people rather than forty. A small convenience sample is directional evidence, not a reliable estimate of the entire market.

4. Test a specific offer

Once the problem is credible, describe the outcome, scope, proposed price, delivery date, and buyer responsibilities. A manual pilot or limited prototype may be enough to test a risky assumption. Do not promise capabilities you cannot deliver.

Look for observable commitments: introducing the budget owner, scheduling a pilot, allocating staff time, or paying for agreed work. A waitlist signup or a hypothetical willingness-to-pay answer is a weaker signal than accepting a concrete offer. Payment is stronger evidence, but a single friendly buyer still does not prove a repeatable business.

Before accepting money, clearly state what the buyer will receive, when, and what happens if you cannot deliver. Track direct costs and the manual work required so an attractive pilot does not conceal an uneconomic service.

5. Make the next decision

Compare the results with the conditions you wrote before researching. Continue when the evidence justifies one bounded next test. Pivot when the problem looks real but the buyer, offer, or delivery method is wrong. Pause or stop when the central assumption lacks support relative to the next cost.

Thresholds should fit the decision and the cost of being wrong. This guide does not prescribe a universal interview count or conversion rate, and its examples are not Killgate's product gate thresholds. Keep technical feasibility, buyer demand, and permission to build as separate questions.

Copy the validation worksheet

Buyer and budget owner:
Recurring task and recent incident:
Current alternative:
Proposed outcome and price:
Riskiest assumption:
Evidence that would disprove it:
Sources and dates:
Qualified people contacted / interviewed:
Observed commitments and refusals:
What remains unknown:
Next test, deadline, and spending limit:
Decision and reason:

Killgate's Idea Validation workflow helps you frame the question and inspect source trails, contradictions, and the next test. Bring direct buyer and payment evidence into the decision rather than treating a report as permission to build.

Further reading: the SBA business-planning guide distinguishes existing market sources from direct customer research. The worksheet and worked example above are Killgate's practical guidance.