Product
What exactly are we building — and not building?
A deliberately lean MVP: booking, Stripe payments, pupil records and a school-admin rollup. Everything AI waits for real usage data before it ships.
- MVP
- Booking calendar, Stripe payments, pupil records + notes, reminders, admin view
- Deferred
- Native apps, in-house payments, live DVSA integration
- Primary risk
- Over-building before product-market fit is confirmed
- Principle
- Ship the smallest thing that kills the admin + payments pain
Booking (single + recurring), Stripe payments (single lessons + packages), a cancellation-policy engine, pupil records with notes, reminders, and a school-admin rollup. Everything else is a fast-follow or waits for data.
No AI feature ships before there's enough booking history to make its predictions meaningful. Bolting on novelty for launch day is a liability, not a differentiator.
A responsive PWA covers the pupil booking need without two extra codebases or App Store release dependencies.
Stripe Connect handles payments — building a payment rail is out of scope permanently, not deferred.
Problem & opportunity
Driving instructors run real, cash-generating small businesses with almost no software support. They lose money to no-shows they can't predict, spend evenings reconciling bank transfers against a paper diary, and have no reliable record of a pupil's progress if that pupil switches instructors or comes back after a break. DriveDesk exists to take the admin and money-chasing off an instructor's plate so lesson time is the only thing they have to think about.
Primary users
| User | Who they are | What they need |
|---|---|---|
| Instructor (sole trader) | Runs their own diary, teaches 25–35 hours/week | Fast booking management, automatic payment collection, pupil progress notes, fewer no-shows |
| School admin | Manages 3–15 instructors under one small-school brand | Visibility across all instructors' diaries, centralised billing, instructor payout tracking |
| Pupil | Books and pays for lessons, tracks own progress | Simple mobile booking, see availability, pay for a lesson or a package, see notes from past lessons |
Core user journeys
- Instructor onboarding. Instructor signs up, sets weekly availability and pricing (per-lesson or package), connects Stripe for payouts, imports or manually adds existing pupils.
- Pupil books a lesson. Pupil receives an invite link (SMS or shared by instructor), creates a lightweight account, sees available slots on a calendar, books, and pays (single lesson or draws down from a pre-paid package).
- Lesson happens, instructor logs notes. After the lesson, instructor adds a quick freeform note (manoeuvres practised, what to work on) which becomes part of the pupil's progress history.
- No-show or late cancellation. Instructor marks a lesson as a no-show; DriveDesk applies the instructor's own cancellation policy (e.g. charge in full inside 24 hours) automatically via Stripe.
- School admin oversight. Admin views a combined calendar across all instructors, sees revenue and payout status per instructor, and can reassign a pupil to a different instructor if needed.
Feature list — MoSCoW
Must have (MVP)
- Instructor account + weekly availability setup
- Pupil account (lightweight, phone-number based)
- Online booking calendar (single lesson + recurring weekly slot)
- Stripe Connect payments: single-lesson payment, pre-paid lesson packages, instructor payouts
- Cancellation policy engine (instructor-configurable no-show/late-cancellation charging)
- Pupil records: contact details, licence status (provisional/full), lesson history
- Freeform lesson notes per pupil, visible to pupil
- SMS + email lesson reminders
- School admin multi-instructor view (calendar + billing rollup)
Should have
- Lesson packages with automatic pupil-facing balance ("6 of 10 hours remaining")
- Mock/practical test date tracking (manual entry, DVSA test centre + date, no live DVSA integration)
- Instructor mobile-friendly "day view" optimised for checking the next pupil between lessons
- Basic reporting: hours taught, revenue, no-show rate, per instructor and per school
Could have
- AI-assisted no-show risk flag on upcoming bookings (see 04 — Architecture for guardrails)
- AI-generated pupil progress summary from freeform notes, for parents/pupils to review
- Referral tracking (pupil refers a friend, instructor sees attributed bookings)
- Calendar sync (Google Calendar / Apple Calendar) for instructors who also keep a personal calendar
Won't have (this release)
- Native iOS/Android apps — see the honest "say no" in 00 — Overview; PWA covers this need at MVP
- In-house payment processing — Stripe Connect handles this; building a payment rail is out of scope permanently, not just deferred
- Live DVSA test-booking API integration — no public API exists for this at time of writing; manual entry is the correct MVP answer
- Instructor-to-instructor pupil marketplace / lead generation between schools
- Multi-currency / non-UK markets
Explicit MVP scope
The MVP is: instructor + pupil accounts, booking calendar, Stripe payments (single lesson and packages), cancellation policy engine, pupil records with lesson notes, reminders, and a school admin rollup view. Everything in "Should have" is a fast-follow within the first 90 days post-launch, not part of the initial build. Everything in "Could have" waits for real usage data — no AI feature ships before there's enough booking history to make its predictions meaningful.
Roadmap
| Phase | Timeframe (post-launch) | Focus |
|---|---|---|
| Launch | Month 0 | MVP feature set above, first 50 instructors onboarded by hand |
| Fast-follow | Months 1–3 | Package balances, test-date tracking, reporting dashboard, calendar sync |
| Intelligence | Months 4–6 | No-show risk flagging, AI lesson-note summarisation (both opt-in, both explainable — see Architecture) |
| Scale | Months 6–12 | School admin features deepen (multi-instructor payroll export, instructor performance benchmarking), referral tracking, native app evaluation once PWA usage data justifies it |
What's deferred, and why
Everything in "Won't have" and the later roadmap phases is deferred for the same reason: build the smallest thing that solves the actual admin-and-payments pain first, get it in front of real instructors, and let their behaviour — not a founder's assumptions — decide what's built next. A niche market this fragmented punishes over-building before product-market fit is confirmed far more than it punishes a lean MVP.
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