Launch
How do we ship it without it falling over?
Testing weighted to payments and access control, a hand-recruited beta, and a deliberately slow, retention-first rollout. No paid ads until day-30/90 retention holds.
- Test priority
- Payments + row-level security on every deploy
- Beta
- 10–15 real instructors, 3–4 weeks, WhatsApp feedback
- Activation
- First paid booking — not signup
- Growth
- Retention first; paid acquisition only after months 3–6
Automated Stripe-test-mode and RLS tests run on every deploy. UI coverage is a lighter manual pass — the money and the data boundaries are where failure is unacceptable.
A signup with no bookings tells you nothing about retention. The real proof the product works is signup-to-first-payment.
The first 90 days prove retention with a small, hand-picked cohort. Spending on ads before retention holds optimises for the wrong market.
A deliberate Stripe test→live cutover with verified webhook endpoints — never a silent config flip on launch day.
Testing strategy
Given the money and personal data moving through DriveDesk, testing priority is weighted toward payments and access control, not exhaustive UI coverage:
| Layer | Approach | Priority |
|---|---|---|
| Payments flow | Automated tests against Stripe's test mode covering: single-lesson payment, package purchase, refund, failed payment, webhook handling | Critical — run on every deploy |
| Row-level security | Automated tests confirming an instructor's Supabase session cannot read another instructor's pupils, bookings, or payment records | Critical — run on every deploy |
| Booking logic | Automated tests for double-booking prevention, cancellation-window charging logic, package balance deduction | High |
| Core UI flows | Manual pass before each release: instructor onboarding, pupil booking, note entry, cancellation | High |
| Cross-browser/device | Manual spot-check on iOS Safari and Android Chrome specifically (pupils and instructors are overwhelmingly mobile) | Medium |
| Load/performance | Not a priority at MVP scale — revisit once past ~500 active instructors | Low at launch |
Beta phase: 10–15 real instructors (recruited by hand from instructor Facebook groups and personal network, per the distribution approach in 01 — Research) use DriveDesk with real pupils for 3–4 weeks before public launch, with a direct feedback channel (WhatsApp group, not a ticketing system — matches how this audience actually communicates).
Analytics & tracking plan
| What | Tool | Why |
|---|---|---|
| Product usage (bookings created, payments completed, notes logged) | PostHog (self-hosted or cloud) | Core activation and retention signal; also feeds the no-show-risk feature's future data needs |
| Marketing site traffic & conversion | Plausible or GA4 | Track instructor signup funnel from /pricing and /features pages |
| Instructor page indexing/impressions | Google Search Console | Directly measures whether the /instructor/[slug] SEO structure (see 05 — Search) is working |
| Payment/error monitoring | Stripe Dashboard + Sentry | Payment failures and application errors need immediate visibility, not end-of-week review |
Key activation metric: an instructor completing their first paid booking, not just signing up — signup-to-first-payment is the real proof the product works for them, since a signup with no bookings tells you nothing about retention.
Key retention metric: instructor still logging in and creating bookings at day 30 and day 90 — set against the assumption in Research that behaviour change is the biggest risk, not technical adoption.
Deployment plan
- Environments: local → preview (automatic per-PR via Vercel) → staging (mirrors production config, used for the beta phase) → production.
- Database migrations: managed via Supabase migrations, version-controlled, applied via CI before each deploy — never run manually against production.
- Stripe: test mode throughout development and beta; a single, deliberate cutover to live mode with its own checklist item (see below), not a silent config flip.
- Rollback: Vercel's instant rollback to the previous deployment covers frontend/API issues; database migrations are written to be additive/backward-compatible wherever possible so a code rollback doesn't strand the database in an incompatible state.
- Domain & DNS:
drivedesk.co.ukprimary; instructor custom-domain support (for those who wantmybookinglink.co.ukinstead of the shared subdomain) is a fast-follow, not launch-blocking.
Launch checklist
- Stripe account switched from test to live mode; live webhook endpoints configured and verified
- All beta-phase bugs from the 10–15 instructor pilot triaged and closed or explicitly deferred
- Cancellation policy defaults reviewed for legal soundness (clear, unambiguous wording shown to pupils before they book, not buried in terms)
- Privacy policy and terms of service live, specifically addressing pupil data handling given some pupils are under 18
- SMS sender ID and email domain (Resend) authenticated (SPF/DKIM) to avoid landing in spam on day one
- Google Search Console verified and sitemap submitted (see 05 — Search)
- Analytics events firing correctly in production for the two key metrics above, verified manually, not assumed
- Support channel live (a monitored inbox or WhatsApp Business number — matching the audience's actual communication habits, not a generic ticketing widget nobody in this trade will use)
- On-call/monitoring in place for payment webhook failures specifically — a missed webhook means a pupil paid but the booking isn't marked as such, which is the single most damaging failure mode this product can have
- Rollback plan tested at least once in staging before go-live, not just documented
Post-launch growth plan
The first 90 days are about proving retention with a small, hand-picked cohort before spending anything on paid acquisition — consistent with the "slow-burn niche SaaS" verdict in 01 — Research:
- Months 0–3: Grow from the 10–15 beta instructors to ~50, entirely through personal outreach, instructor Facebook groups, and word of mouth. No paid ads yet — the goal is validating that instructors who sign up actually stay, not maximising signup volume.
- Months 3–6: Once day-30/day-90 retention looks healthy (a real threshold to define once early data exists, not guessed today), begin light paid acquisition targeting the "software/booking" keyword cluster from 05 — Search, alongside the first wave of blog content.
- Months 6–12: Lean into the compounding SEO effect of live
/instructor/[slug]pages, begin structured outreach to small driving schools (3–15 instructors) as a distinct, higher-value segment from solo instructors, and revisit the "Could have" AI features (no-show risk, note summarisation) now that there's genuine usage data to build them on.
Growth here is deliberately paced to the trust-based, word-of-mouth nature of the trade identified in Research — a founder expecting rapid, ads-driven growth in month one is optimising for the wrong market.
Six documents · £8,000 fixed · ~3–4 weeks
Scoped to your real product or internal system — not this fictional one.
Book a Blueprint call Back to overview