A Multi-Tenant SaaS for Driving Instructors

Overview

PupilTrack was a management platform for driving instructors in the UK, from sole traders up to schools running several instructors between them. It covered the part of the job that happens outside the car: pupils, lesson scheduling, payments and progress tracking, in one place rather than spread across a paper diary, a spreadsheet and a banking app.

I started it as a chance to build something I had a genuine interest in, and to learn what taking a product from nothing to fully shipped actually involves. The subject was not arbitrary: I enjoy driving, I hold both car and bus licences, and I have an interest in road safety and driver training.

I designed it, built it, shipped it and ran it on my own. The first version went out in August 2025.

What I built

The platform was organised around an instructor’s working week:

• Scheduling — a calendar that checked for clashes before a lesson was booked or moved, including vehicle double-booking and the travel time between one pupil’s address and the next.
• Payments — lesson costs, per-lesson overrides, and payment tracking, with Stripe handling subscription billing for the instructors themselves.
• Progress tracking — a competency framework recorded lesson by lesson against each pupil. Pupils could be invited to their own login and follow their own progress.
• Lesson reminders — an email to the pupil about an hour before each lesson. A scheduled job ran every ten minutes and picked up lessons 54 to 66 minutes out: six minutes either side of the hour, so that a ten-minute cadence could never send the same pupil the same reminder twice.
• Financial reporting — revenue, outstanding payments and average hourly rate over a chosen period, broken down by pupil, exportable to PDF.

Multi-tenancy and access control

The tenant is an organisation, and a sole trader is simply an organisation of one. Members hold a role within it — owner, manager or instructor — and pupils are separate users again with access to their own records and nothing else.

Isolation is enforced by the database, not by application code. Postgres on Supabase carries row-level security on twenty-five tables, with policies written against auth.uid() and a helper that resolves the caller’s organisations and roles. Owners and managers see their whole school; an instructor sees their own pupils, lessons and financials; a pupil sees their own progress.

Nothing in the application holds a privileged database connection for ordinary work. Queries run as the signed-in user, so a query that forgot to filter by organisation came back empty rather than carrying another school’s data. The two scheduled jobs are the deliberate exception, and they run server-side with a service role rather than on behalf of any user.

There is also an append-only audit log, with a weekly job recording a head hash of it so the chain can be checked for tampering after the fact.

The stack

Next.js on the App Router with React and TypeScript, styled with Tailwind CSS. Supabase provided Postgres, authentication and row-level security, accessed through the Supabase client rather than an ORM — which is what keeps every query subject to those policies. Stripe handled subscription billing and seat counts, Resend sent transactional email, and the whole thing ran on Vercel, whose cron scheduler drove the reminder and audit jobs.

That is close to the stack I use for client projects. Running something on it myself meant living with those decisions over time rather than handing them over at launch — the maintenance, the upgrades and the bugs all stayed mine.

Status

PupilTrack was retired in 2026 and is no longer available.

What I learned

Two things, and neither of them was the code.

The first was marketing and distribution. Building the product was the part I already knew how to do. Getting it in front of driving instructors, describing it in terms that meant something to them, and turning interest into someone actually signing up was a separate skill, and one I had to learn from scratch.

The second was security. In a multi-tenant product every customer’s data sits in the same database, and that changes what being careful means. Enforcing isolation in the database rather than trusting application code to filter correctly, keeping privileged credentials out of anything that runs on a user’s behalf, and keeping an audit trail that can be checked afterwards — those went from things I understood in principle to things I had to get right in production.