Micro-SaaS operating guide
A practical route through problem signals, customer interviews, competitor analysis and pre-code tests.
Building can hide the riskiest assumption: that a specific customer cares enough about this problem to change what they do.
Use the guides below to examine the current workflow, interview people without pitching them, study existing alternatives and ask for evidence that carries a real cost.
Validation gets useful when each step asks for more than an opinion. Begin with the problem as it happens today, then look for behaviour that costs the customer time, money, attention or control. Only after that should you ask for a commitment.
Ask for the last time the problem occurred. Who noticed it? What triggered the work? Which files, messages or systems were involved? An interview can reveal the language and shape of the problem, but enthusiasm about a future product is still an opinion.
A spreadsheet, repeated copy-and-paste, a contractor or a calendar reminder shows that someone is spending effort to complete the job now. A tolerated error shows the cost of leaving it unresolved. These signals are stronger than a complaint because they expose trade-offs, but they do not prove that software is the preferred answer.
Invite the right person to share data, introduce the workflow owner, schedule a pilot, sign a letter of intent or pay for a defined test. The appropriate ask depends on the buyer and the risk. A commitment matters because declining it gives you information too.
| Evidence | What it can tell you | What it cannot settle | Sensible next move |
|---|---|---|---|
| Interview account | The incident, vocabulary, people involved and current consequences. | Whether the problem repeats often enough or deserves budget. | Ask for a recent example and inspect the workflow around it. |
| Existing workaround | How the job gets completed, where friction appears and who absorbs it. | Whether the customer wants to replace that workaround now. | Offer a manual version of one outcome and watch what they provide or change. |
| Commitment | Whether the problem survives an ask for access, time, reputation or money. | Whether a broad market exists or the eventual product will retain customers. | Define the smallest test, its owner, its success condition and the follow-up date. |
Do not average weak signals into a strong one. Ten polite conversations do not become a pilot, and a detailed workaround does not become willingness to pay until you ask.
If the problem is still vague, start with the business-problem signals. If conversations drift into feature requests, use the interview guide and return to a specific past incident. If the workaround is clear but demand is not, study competitors and run a pre-code test. Move toward the cards below only as far as the evidence allows.
Validation
Use source IDs to choose the target job, exclusions, switching costs, proof requirements and first-version scope.
Write down the customer, the last observed incident, the current workaround and the assumption you still need to test. Then choose one ask that exposes that uncertainty. If the person will discuss the problem but will not take a next step, whether sharing an example, introducing you to the owner or trying a manual test, record the gap instead of explaining it away.
