Micro-SaaS operating guide
Scope the critical flow, place manual work deliberately, and decide whether the product is ready for a first pilot.
A smaller feature list does not create a viable pilot. The product still needs to carry one customer from a realistic starting point to a result they can use.
Use this collection to define that critical flow, choose where manual work belongs, protect customer data and access, and prepare a first account for the test.
Write the shortest path from a customer's starting state to the outcome they came for. Name the input they provide, the transformation your product performs, the result they receive and the action they take with that result. If a step can disappear without breaking the outcome, it is outside the critical flow for this pilot.
Protect the full loop before polishing any single screen. A narrow workflow that reaches a dependable result is more useful in a pilot than a wide product with gaps between its features.
Manual work is acceptable when it helps you learn an uncertain step and the customer still receives the promised outcome. It becomes dangerous when it hides a reliability problem, creates an unspoken service obligation or cannot be performed within the pilot's expected pace.
A pilot does not require every edge case. It does require a named user, a defined job, safe access, a working critical flow, visible limits and a support route. Agree on what the pilot includes, what remains manual, how issues will be reported and what decision follows the test.
If an account is waiting, use “Write the pilot boundary in plain English” below. If the build has several competing paths, return to “Draw the critical flow before you choose features” on this page. If you are unsure what to automate, use “Place the manual boundary on purpose” above. The recoverable first-session article helps define the start, result and failure branch. The fictional security records expose missing recovery and access checks. If the reason to build is still uncertain, prepare a pre-build decision dossier.
Pilot evidence
Use manual delivery and commitment tests to find the part of the job that deserves software.
First useful result
Clarify the promise, required inputs and recovery path before polishing signup screens.
Safe pilot
Read fictional backup, restore, exposed-credential and access-log records to distinguish a completed job or deleted screenshot from a verified result.
Name the user, the job, the starting input, the promised result and the support window. List every manual step beside the person responsible for it. Then state what the pilot will not do. If you cannot describe the boundary without giving a product tour, the critical flow is still too hard to see.
Hypothetical pilot boundary; not a launched product or a PBT service commitment: a pilot user submits one sample CSV with fictional data for validation, manual review and export of approved rows. In this example, the pilot owner reviews flagged rows and handles recovery. Support is limited to one agreed review session on a weekday. Live customer data, integrations and reminder sending are excluded. Invalid rows or a failed job stop the export; the operator records the issue and restarts from the original sample only after checking the correction. No reminder is sent.