Sample artefact

A flight plan.

This is the document that comes out of stage 02 — the thing you actually get before anyone writes code. It says what the first launch is, what it is not, and what we will know at the end of it.

The mission below is fictional. No client work is published here without permission, and none is published yet.

Kestrel — Flight Plan
Mission SP-0041 · Revision 1.2 · Prepared 12 March
Approved for build
Founder
Non-technical, previously ran operations for a courier network
Engagement
Launch — idea to MVP
Build window
9 weeks from kickoff to public launch
Crew
1 product engineer, part-time design
Launch date
14 May — 12 pilot customers already committed
01

The mission

Independent physiotherapists in South Africa run their practices on WhatsApp, a paper diary and manual EFT reconciliation. Booking a session takes four messages. Roughly one appointment in six is a no-show, and chasing payment afterwards is the part everyone hates.

The hypothesis: a solo practitioner will pay a monthly fee for a booking link that takes card payment up front, if it removes the back-and-forth and the no-shows.

The riskiest assumption: not whether practitioners want this — they say they do — but whether their patients will pay up front for a service they are used to paying for afterwards. If patients abandon the booking at the payment step, the whole model changes.

What counts as a yes: across 12 pilot practices in 6 weeks, at least 60% of started bookings reach payment, and at least half the practices are still using it in week 6 without being nudged.


02

The smallest product that tests it

One workflow, end to end: a patient books and pays; the practitioner sees it. Everything else waits.

In the first launch

  • Practitioner sign-up and a public booking page
  • Availability set as weekly recurring hours
  • Patient books a slot and pays by card (Yoco)
  • Confirmation and reminder by WhatsApp
  • Practitioner’s day view, with cancel and refund
  • Funnel analytics on every step of the booking

Deliberately not yet

  • Multi-practitioner practices. 80% of the market is solo. Adds roles and permissions to every screen.
  • Calendar sync. Two weeks of work and a permanent support burden; the day view answers the same need for now.
  • Clinical notes. Regulated, and irrelevant to the hypothesis.
  • Medical-aid claims. The real long-term prize, and the fastest way to spend six months not launching.
  • A native app. Patients arrive from a WhatsApp link. A web page is the correct shape.
  • An admin panel. Twelve pilot practices can be managed from the database by us.

03

Systems & decisions

Boring, cheap, and easy to hand to somebody else. Every choice here is reversible except the first one.

Technical decisions
Recorded, with reasons
Application
One Next.js app, server-rendered · no separate API to maintain yet
Data
Postgres, one schema, migrations from day one
Payments
Yoco · local cards, local support, no merchant account required
Messaging
WhatsApp Business API · the channel patients already use
Hosting
Single region · roughly R900 a month at pilot scale
Ownership
Founder’s GitHub organisation and cloud accounts from commit one
Reviewed at launch · nothing here is load-bearing enough to be expensive to change

04

Milestones

Nine weeks
Something to click on every Friday
Week 1–2   Booking flow, deployed and clickable
Shipped
Week 3–4   Payment, refunds, the failure cases
Shipped
Week 5–6   WhatsApp confirmations and reminders
Shipped
Week 7      Practitioner day view, three pilots onboarded
In progress
Week 8      Systems check, analytics, real bookings from staff
Planned
Week 9      Launch to 12 pilot practices
Planned

05

Open questions and risks

R1

Patients may not pay up front

The central risk, and the reason the funnel analytics are not optional. If drop-off at payment is severe, the next mission is a deposit rather than full payment — a small change we have deliberately left room for.

R2

WhatsApp template approval is outside our control

Meta approval has taken between two days and three weeks in our experience. Submitted in week 1; email is the fallback so the launch date does not depend on it.

R3

Twelve pilots is a small sample

Enough to kill the idea, not enough to prove it. A clear yes here means a second, larger mission — not a scale-up.

R4

Refund policy is a business decision, not ours

Needed before launch. Flagged in week 2 so it does not become a week 8 emergency.


06

What we will know on 14 May

Whether patients will pay before a session. Whether practitioners keep using it once the novelty wears off. Which of the six deferred features gets asked for first — which is the cheapest possible way to find out what the second mission should be.

If the answer is no, it will have cost nine weeks and one clear paragraph will explain why. That is the point of launching early: reality gets a vote.

Approved for build
Mission SP-0041 · Kestrel · Rev 1.2

Kestrel is a fictional mission written to show the shape of the document. Every figure in it is invented.

Bring us the mission.

Tell us the idea, the problem or the half-built thing. We’ll tell you what the smallest worthwhile first launch looks like.