Validate a micro-SaaS idea by testing its riskiest expensive assumption with observable customer behavior before you write the product. A short landing page, a concierge delivery, or a carefully scoped pre-sale can be more useful than a week of polished code if it tells you whether a specific person will take a specific next step.
The goal is not to prove that the idea is universally good. It is to decide what you should do next: build one narrow workflow, change the audience or problem, run another test, or stop. That decision gets clearer when you separate compliments from evidence.
Start with one testable claim
“Freelancers need a better invoice tool” is too broad to validate. It bundles a customer segment, a problem, a workflow, a price, and a solution into one sentence. A useful first claim identifies all three parts you need to learn from.
- Customer: a narrow group you can actually reach.
- Problem: a recurring job, failure, delay, or cost they already experience.
- Outcome: a result they would take a concrete step toward getting.
For example: “Independent Shopify consultants who manually reconcile client payouts each week will book a paid setup call for a concise reconciliation report.” This may still be wrong. Its value is that it can be tested without building an integrations platform.
Write the claim in this format:
We believe [specific customer] has [recurring problem] and will [observable action] to get [specific outcome].
Then identify the assumption that would make the whole idea fail if it were false. It is usually not “Can I build this?” For a solo founder, it is more often whether the problem is frequent enough, whether the audience can be reached, or whether the proposed outcome is worth changing behavior for.
Use the smallest credible evidence loop
Do not begin with a feature list. Begin with a learning goal and choose the smallest artefact that can test it. Strategyzer makes the same distinction in its guidance on experiment design: the test artefact should be designed around the learning goal, rather than becoming a smaller version of the eventual product.
Original asset: a micro-SaaS validation worksheet
- Risk: What must be true for this idea to be worth building?
- Evidence today: What have you personally observed, and what is only an assumption?
- Test: What single action would reduce the uncertainty?
- Commitment: What will count as behavior rather than an opinion?
- Decision rule: What result means build, narrow, retest, or stop?
Keep one hypothesis per experiment. If you change the audience, promise, price, and channel at once, an encouraging result will not tell you what caused it. If you need a competitive baseline, list the alternatives a buyer uses today: a spreadsheet, a virtual assistant, a general-purpose tool, an agency, or doing nothing. The U.S. Small Business Administration similarly separates market research from competitive analysis and recommends direct research for questions about a specific customer or offer.
Run interviews about past behavior, not future enthusiasm
Interviews are for discovering the language, frequency, workaround, and consequence of a problem. They do not validate a solution on their own. A person can sincerely say they would use an app and never make room for it in their day.
Recruit people who match the customer in your claim, not merely friends who like SaaS. Ask for a brief conversation about how they handle the situation now. You are looking for concrete episodes, artifacts, and trade-offs.
Copyable interview script
- “Tell me about the last time you had to [do the job].”
- “What happened first, and what made it difficult?”
- “How often does that situation occur?”
- “What do you use today to handle it?”
- “What does the workaround cost in time, money, missed revenue, or stress?”
- “Have you tried to fix it before? What did you choose and why?”
- “Who else is involved when this happens?”
- “May I follow up if I test a narrower way to solve this?”
Avoid leading questions such as “Would you pay for an AI tool that solves this?” They turn the conversation into a request for approval. Instead, record exact past behavior: what they did, what they paid, what they abandoned, and what event made the problem urgent. Treat a story as a signal to investigate, not a vote to tally.
Choose a smoke test that asks for a real commitment
Once the interviews reveal a repeated problem and a clear audience, test the proposed outcome. A smoke test is not a deceptive launch. It is an honest, limited offer that lets a person take a meaningful next step while you learn.
Use a landing page when the message is the risk
Write one page for one customer and one job. State the current painful moment, the promised outcome, the boundaries of the offer, and one call to action. Measure a commitment that costs the visitor something appropriate to the stage: a qualified call request, a request to join a small pilot, or permission to see a scoped prototype. A raw page-view count is not validation because it does not show whether the right people understood the promise.
Use a concierge test when the workflow is the risk
Deliver the outcome manually for a few qualified people. If the idea is a weekly reconciliation report, create the report with the data they already export and learn where the hard work actually sits. This can expose missing inputs, trust concerns, review steps, and the parts a customer values before you automate any of them. Be explicit that the service is manual or pilot-stage.
Use a pre-sale only when the scope is honest
A pre-sale can test willingness to pay, but only if the buyer sees the price, delivery timing, refund terms, and what is not included. Do not take payment for an undefined future product. If you are not ready to make that commitment, ask for a scheduled discovery call or a pilot agreement instead.
Score the result before you see it
Set your decision rule before promoting the test. This prevents a flattering response from becoming a reason to build an unrelated product. The following six-point scorecard is a planning aid, not a benchmark.
Give one point for each signal
- The interviewee describes a recent, repeated problem without being prompted.
- The current workaround has a visible cost or meaningful downside.
- The person matches the narrow audience you selected.
- The proposed outcome is understood without a long explanation.
- The person takes the commitment you asked for.
- The commitment comes from more than one qualified person or channel.
Five or six points: define the smallest paid or production-capable workflow you can build next. Three or four: narrow the audience, revise the promise, or repeat the test with a single changed variable. Zero to two: stop or return to problem discovery. The point is not to manufacture a passing score; it is to make the next decision visible.
A five-day validation plan
- Day 1: Write one customer-problem-outcome claim, list current alternatives, and set a decision rule.
- Day 2: Recruit qualified interviewees through the places that audience already works, learns, or buys.
- Day 3: Run interviews and note recurring episodes, language, workarounds, and follow-up permissions.
- Day 4: Build one honest smoke-test artefact: a landing page, concierge offer, or scoped pilot invitation.
- Day 5: Compare the commitments with your rule, document what changed, and choose build, narrow, retest, or stop.
Do not add an app because the test feels slow. If people will not discuss the problem, cannot recognize the outcome, or will not take the next step, more implementation usually creates more untested assumptions.
When you have enough to build
Build when you have evidence that a reachable, specific audience experiences a recurring problem and will take a meaningful step toward a defined outcome. That is not a guarantee of product-market fit, security, distribution, or long-term retention. It is enough to choose a deliberately small first workflow and keep learning from real use.
If you do start building, retain the same discipline: make one assumption visible, instrument the behavior that matters, and keep the next experiment smaller than the product roadmap. AI coding tools can reduce implementation time; they do not remove the need to decide which customer problem is worth implementing.
Use the worksheet before you make a build plan
Copy the validation worksheet above into your notes, run one interview round, and choose one honest smoke test. The useful result may be a narrower idea or a decision not to build. Both are cheaper and clearer outcomes than shipping an untested feature set.
