Most micro-SaaS ideas fail for a boring reason: the founder spent the first week building instead of learning whether a specific person wants a specific outcome.
Here is a seven-day validation sprint that produces evidence before a code sprint. It is deliberately small. The goal is not to "prove the market" in a week; it is to decide whether the next week deserves more effort.
Day 1 — Name one narrow problem
Write one sentence in this form:
[Person with a context] struggles to [complete a job] because [friction].
Avoid a persona such as “small businesses.” Prefer “freelance designers who lose leads because proposal follow-up lives across email and WhatsApp.” A narrow problem gives you a way to find people and to recognize useful replies.
Day 2 — Make your assumptions falsifiable
List the three assumptions that must be true for the offer to matter:
- The problem happens often enough to be memorable.
- The current workaround is costly, slow, or frustrating.
- People will exchange money, time, or access for a better outcome.
For each assumption, decide what evidence would change your mind. For example, five people saying “I already solved that with a spreadsheet and it takes two minutes” is useful negative evidence.
Day 3 — Ask about the past, not opinions
Use short questions that invite concrete stories:
- “Tell me about the last time this happened.”
- “What did you do instead?”
- “What did that cost in time, money, or missed opportunities?”
- “What have you already tried?”
Do not lead with your solution. “Would you use an app that…” mainly measures politeness. A recent example reveals behavior.
Day 4 — Reach five relevant people personally
Send five focused messages, not a blast. Tell the truth: you are researching a narrow workflow and want a 15-minute conversation. If nobody responds, that is a signal about either your audience, message, or problem urgency.
Keep a simple log with the person, their current workaround, the exact phrase they used to describe the pain, and whether they agreed to talk again.
Day 5 — Turn the strongest pain into a one-page offer
Your page needs only four pieces:
- A headline that repeats the problem in the customer’s language.
- A tangible outcome, not a feature list.
- A small explanation of how it works.
- One action: reply, join a waitlist, reserve a pilot, or pre-order.
If you cannot explain the offer in one page, the idea is probably still too broad.
Day 6 — Ask for a commitment
The strongest early signal is not a like. It is a commitment that costs something: a calendar slot, access to real data, a pilot agreement, or a small pre-order.
Be transparent about the stage. A useful line is: “I am testing whether this is worth building. If I can solve this for you, would you be willing to reserve a pilot?”
Day 7 — Make a decision from evidence
At the end of the sprint, choose one:
- Double down: repeated pain, a costly workaround, and at least one real commitment.
- Refine: the pain is real but the segment, wording, or outcome needs work.
- Stop: the evidence does not support another build week.
Stopping an unvalidated build is a win. It protects your time for the next test.
A simple scorecard
Before writing code, rate the opportunity from 1–5 on urgency, frequency, ability to reach buyers, willingness to commit, and your ability to deliver a first manual version. The total is less important than the explanation behind each number.
If you want a reusable Spanish-language guide and calculator for this sprint, I made the Kit de Validación Rápida. The same page also offers a transparent, fixed-price Express Audit for one landing page or pre-sale offer; it is paid directly in SOL and does not promise revenue.``
If you already have a defined offer and need the actual page rather than another framework, Launch Page Sprint is a fixed-scope, custom-coded landing-page build for USD 149. It includes one responsive page, focused copy, source files, and two revision rounds; it does not include paid traffic or sales guarantees.
