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, study existing alternatives and choose a bounded test for the uncertainty you need to resolve. Participation, access and data sharing require their own checks and agreement.
Choose evidence for the uncertainty you need to resolve. An account of a past incident can clarify what happened, a workaround can expose current trade-offs, and a bounded commitment can test a specific next step. These are different questions, not a universal ranking; a more demanding ask is not automatically more informative.
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 can show how someone completes the job now. Record the effort and consequences you can actually establish; a tolerated error does not reveal its cost by itself. Workarounds expose trade-offs. They do not establish demand, available budget or a preference for software.
Choose a bounded next step that addresses the missing fact, such as an introduction to the workflow owner or a defined pilot. Before asking for data or access, confirm who can authorize it and agree on the purpose, minimum information and handling limits; use a redacted example where possible. A refusal may reflect confidentiality or lack of authority, so record the reason only if it is given.
| 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 the person is authorized to discuss; agree on observation and note-taking limits before inspecting the workflow. |
| Existing workaround | How the job gets completed, where friction appears and who absorbs it. | Whether the customer wants to replace that workaround now. | Agree on a bounded manual test, including permitted access and the minimum data needed; use redacted material where possible. |
| Commitment | Whether this person agrees to a defined next step under the stated conditions. | Whether a broad market exists or the product will retain customers. Refusing data or access may reflect confidentiality or limited authority, not lack of interest. | Define the smallest permitted test, its owner, success condition, data limits and agreed follow-up date. If no reason is given for a refusal, record the reason as unknown. |
A polite conversation, a detailed workaround and agreement to a pilot answer different questions. None on its own establishes demand or willingness to pay. Record what happened separately from what you think it means.
If the riskiest assumption is unclear, use the pre-build decision dossier: which missing fact could change the decision? If current alternatives are poorly understood, use competitor analysis: which jobs do the alternatives support, what do they exclude, and how would switching costs affect your scope? If a handoff is assumed, prepare an authorized workflow observation: who moves which information to whom, and what remains unknown?
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.
