Pink Banana Tools

Micro-SaaS operating guide

Build a micro-SaaS MVP without overbuilding

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.

Draw the critical flow before you choose features

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.

  1. Entry: the customer can start with the access, data and instructions they realistically have.
  2. Core action: the product completes one coherent job without forcing the founder to explain missing steps in a call.
  3. Result: the customer can recognise whether the output is usable, incomplete or wrong.
  4. Recovery: bad input, failed processing and account problems lead somewhere clear.
  5. Return: the customer knows what to do the next time the job occurs.
Scope rule

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.

Place the manual boundary on purpose

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.

Keep manual for now

  • One-off setup that reveals how customer data varies.
  • Review of an output whose quality rules are still being learned.
  • A small integration handoff that you can track and explain.
  • Support conversations that show where onboarding fails.

Resolve before the pilot

  • Security or permission steps handled differently each time.
  • Silent failures that only the founder can detect.
  • Core processing that depends on memory or late-night intervention.
  • Work the customer believes the product performs automatically.

Decide whether the product is ready for a pilot

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.

Read the pilot checklist first if an account is waiting. Use the critical-flow guide when the build still has several competing paths. Read the concierge MVP note when automation is consuming time before the workflow is understood. The technical debt and activation articles matter once the loop works but feels fragile, or when users stop before reaching the result.

MVP reading path

Write the pilot boundary in plain English

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.