How We Built PassReady — The Tech Behind the UK's First Free Driving Instructor Platform

A solo developer, six key technology choices, and the reasoning behind every one of them. This is how PassReady went from idea to production.

When I started building PassReady, I had one constraint that shaped every decision: I was building it alone. No engineering team. No DevOps department. No QA testers. One developer, responsible for the frontend, the backend, the payments, the infrastructure, the deployment, and the content.

That constraint turned out to be an advantage. Every technology choice had to earn its place. If something created maintenance burden, it was out. If something required a team to operate, it was out. The result is a stack that is modern, fast, secure, and — critically — manageable by one person.

Here is every major technology decision and why I made it.

Frontend: React + Vite + TypeScript

The frontend is built with React, bundled with Vite, and written entirely in TypeScript.

React was the obvious choice for a few reasons. The component model means every piece of the interface — booking calendars, student progress cards, payment forms, instructor dashboards — is a self-contained module that can be developed, tested, and updated independently. When I need to change how the booking calendar works, I change one component. Nothing else is affected.

Vite replaced Create React App as the build tool because it is dramatically faster. Hot module replacement during development is essentially instant. Production builds are smaller and faster. For a solo developer spending hours in the editor, those seconds add up to real productivity.

TypeScript was non-negotiable. When you are the only developer, you do not have a colleague to catch your type errors in code review. TypeScript catches them at compile time. It also serves as living documentation — the type definitions for a booking, a student record, or a payment transaction describe exactly what shape the data takes. Six months from now, when I come back to code I wrote today, the types will tell me what I was thinking.

Backend: Firebase (Firestore + Cloud Functions + Hosting)

This is probably the most consequential decision in the entire stack. PassReady runs on Firebase — Google's application platform — rather than a traditional server.

That means:

• No servers to maintain. No Linux boxes to patch. No Nginx to configure. No SSH keys to manage. No 3am alerts because a process crashed. The infrastructure is fully managed by Google.
• No database administration. Firestore is a NoSQL document database that scales automatically. I do not configure replicas, manage indexes manually, or worry about connection pooling. I write data, I read data. Google handles the rest.
• Automatic scaling. If PassReady has ten users today and ten thousand next month, the infrastructure adjusts without any intervention. I do not need to provision bigger servers or reconfigure load balancers. This is built into the platform.
• Usage-based pricing. Firebase charges based on reads, writes, and bandwidth. When the platform is quiet, costs are minimal. This is the foundation of PassReady's no-monthly-fee pricing model — my infrastructure costs scale with usage, so customer pricing can too.

Cloud Functions handle the server-side logic: processing payments, sending notifications, enforcing business rules, running scheduled tasks. They execute on demand and cost nothing when idle. A traditional server would run continuously whether anyone was using it or not.

Firebase Hosting serves the frontend via Google's global CDN. The app loads fast from anywhere in the UK because the static assets are cached at edge locations across the country. First contentful paint is under a second on a decent connection.

For a solo developer, Firebase eliminates an entire category of work. I never think about servers. I think about the product.

Payments: Stripe Connect

Stripe Connect is the payment infrastructure behind PassReady, and choosing it solved several problems at once.

PassReady is a marketplace — students pay, instructors receive. That means card numbers need to go from the student to Stripe, money needs to be split between the instructor and the platform, and none of the sensitive payment data should ever touch PassReady's servers. Stripe Connect handles all of this.

• Card numbers never reach us. Payment forms are rendered by Stripe's JavaScript library. The card number goes directly from the student's browser to Stripe's servers. PassReady never sees it, never stores it, never transmits it. This is PCI compliance by design, not by effort.
• Automatic fee splitting. When a student pays £38 for a lesson, Stripe automatically deducts PassReady's 4.2% and routes the remainder to the instructor's connected Stripe account. No manual calculations. No monthly invoicing. No reconciliation.
• Instructor onboarding. Stripe Connect handles identity verification, bank account linking, and regulatory compliance for each instructor. The onboarding flow is Stripe's, not ours, which means it is maintained and updated by a company that processes billions in payments annually.

This is the same payment infrastructure used by Deliveroo, Shopify, and Lyft. It is not an experiment. It is the standard for marketplace payments at any scale.

Geographic matching: Postcodes.io

Driving instructors have coverage areas. A student in Ipswich should not be matched with an instructor who only covers Norwich. Solving this requires turning postcodes into geographic coordinates and calculating distances.

Postcodes.io is a free, open-source API that does exactly this. Give it a postcode, get back latitude, longitude, and administrative geography. It is maintained by Ideal Postcodes, it runs on open data from Ordnance Survey, and it costs nothing to use.

When a student enters their postcode on a PassReady booking page, the platform checks whether they fall within the instructor's coverage area using Haversine distance calculation against the instructor's defined radius. This happens in milliseconds, with no cost per lookup.

The alternative would have been Google's Geocoding API, which charges per request. For a platform trying to avoid passing costs to instructors, a free alternative that runs on authoritative government data was the obvious choice.

Coverage maps: Leaflet

Instructors need to see and define their coverage area visually. Students need to check whether an instructor covers their location. Both of these require an interactive map.

Leaflet is an open-source JavaScript mapping library that renders interactive maps using OpenStreetMap tile data. It is lightweight (about 40KB), fast, mobile-friendly, and free. The instructor's coverage area is drawn as a circle on the map, centred on their base postcode with a radius they define.

Google Maps would have been the premium option. It is excellent, but it costs money per map load and per interaction. For a platform with no monthly fees, adding a per-map-load cost to every page view would eventually force a pricing change. Leaflet with OpenStreetMap tiles is free at any scale.

The maps render instantly, they work on mobile, and they do everything PassReady needs. Not every technology choice has to be the most expensive one.

Promo videos: Remotion

This is the unexpected one. Remotion is a framework for creating videos programmatically using React. Instead of editing video in Premiere or After Effects, you write React components that render as video frames.

I used Remotion to generate PassReady's promotional videos. The benefit is that every element — text, animations, transitions, branding — is defined in code. If I need to change the pricing, update a feature description, or create a version for a different audience, I change the code and re-render. No video editing skills required. No timeline dragging. No re-exporting at different resolutions manually.

For a solo developer who is not a video editor, Remotion turned video production from a multi-day creative project into a code change and a render command. The PassReady demo video was built this way.

What I deliberately did not use

The choices you do not make matter as much as the ones you do.

• No WordPress. WordPress powers a huge portion of the web, but it requires ongoing maintenance — updates, security patches, plugin compatibility. For a solo developer, that maintenance is time not spent building features. Firebase Hosting serves static files with zero maintenance.
• No traditional database. PostgreSQL or MySQL would have required a managed database service, connection management, migration scripts, and backup configuration. Firestore eliminates all of that.
• No Docker or Kubernetes. Container orchestration is powerful, but it is designed for teams managing complex deployments. A solo developer does not need Kubernetes. Firebase deployment is a single command: firebase deploy.
• No third-party analytics bloat. No Google Analytics. No Hotjar. No tracking pixels. PassReady does not sell attention. It does not need to track every click to optimise an advertising funnel.

The result

PassReady is a production application that handles bookings, processes payments, manages student records, and serves an interactive demo — all running on infrastructure that costs almost nothing when idle and scales automatically when busy.

It was built by one developer in a home office. Not because one developer is all it deserved, but because modern tooling makes it possible for one person to build something that would have required a team of ten a decade ago.

The driving instructor software market is full of platforms built on ageing technology by companies with significant overheads. Those overheads get passed to instructors as monthly subscriptions. PassReady's technology choices mean the overheads do not exist, which is why the pricing model works.

If you are a developer interested in the stack, I am happy to discuss the decisions in more detail. If you are a driving instructor, the technology is not the point — the point is that it works, it is fast, and it does not cost you a subscription. Try the demo and see for yourself.