SteadyRides is a booking and dispatch platform I designed and built for a Connecticut car service that specializes in airport rides. Clients book in a few taps, drivers pick up the rides that fit their car, and the owner runs the whole day from one dashboard. I designed every screen for all three roles and built the working app end to end, from the booking flow to card payments.
A ride to the airport sounds simple. In practice, flights move, a round trip spans days and often two different drivers, children need the right car seat by law, business travelers need an invoice for their employer, and plans fall apart for real reasons: an expired passport, a cancelled flight, a family emergency.
My client needed one place where clients could book, drivers could take rides, and the owner could see and manage all of it, without the details falling through the cracks between them.
I wanted to understand the service from both seats before designing it, so as part of my research I drove for Uber. It showed me what drivers need between rides, where they lose time at airports, and what riders worry about on the way to a flight.
I paired that with how my client's business actually runs, and with Connecticut's rules for ride services: fares have to be paid through the platform, and children under 8 or under 60 pounds must ride in a car seat or booster. Those rules became part of the design rather than fine print.
Many riders book the night before a flight, on a phone, often in a hurry. So booking asks one thing at a time: where you're flying, your flight, who's coming, where to pick you up. The pickup time is worked out from the flight, and the price updates as you go.
Only cars with room for everyone, every bag and every car seat are offered. A round trip can come home to a different airport, and each child gets the seat they need, from infant seat to no seat at all.
The hardest case shaped the whole system: a family with a toddler books a round trip, and the driver who takes them to JFK isn't the one who picks them up a week later. They don't want to drag a car seat through the airport.
Each leg of a round trip is its own ride, so any driver can take it. The client can ask the service to keep the seat for a storage fee. The first driver sees "keep the seat and hand it to Priya," the second sees "pick up the seat from Mike first," and the two can message and call each other in the app to arrange it. The fee is split between them, and the owner sees the handoff on the board until it's done.
Every action in one role shows up in the others. When a driver taps "I'm on my way," the client sees it in their trip, and the owner's board updates. A ride still unclaimed within 24 hours of pickup is flagged as urgent so the owner can assign it.
The owner gets a live board, a calendar, quote requests for trips that aren't airport runs, a client list that can import a spreadsheet, and a view of every driver's fees.
Most of the design work went into the moments that usually happen over the phone. A trip checklist reminds travelers about passports and visas before they leave. Clients can ask to cancel and say why; the owner approves it, with a full refund when there's enough notice.
Drivers get a guide for each airport: where they can wait for free instead of circling or risking a ticket at the curb, with one tap to navigate there, plus a link to the flight's live status. Work travelers confirm their invoice details after the trip, so booking never stops to ask.
The platform is meant to be licensed to car services in other states, and no two run the same way. So the decisions that differ between businesses are settings the owner controls: whether payments run through the app, the booking fee, how much notice earns a full refund, and the late cancellation fee.
Drivers who carry their own commercial insurance pay a different plan than drivers covered by the company, and each driver sees exactly what the app charges them. Tips are never charged.
I used Claude throughout, to build interfaces in code, to research Connecticut's rules, and to move from an idea my client mentioned to a working screen the owner could try right away.
Every version was checked with automated browser tests that book rides, accept them as different drivers, cancel, and pay, before it reached my client. That let me change the product quickly without breaking what already worked, and spend my time on judgment: what a rider, a driver or an owner actually needs to see.
SteadyRides is a web app that installs to a phone's home screen like a native app, built with Next.js. Card payments run through Stripe, with the price checked again on the server so it can't be changed in the browser. New bookings, quote requests and cancellation requests email the owners.
Building it myself meant every design decision was tested against a working product, not a mockup, and the owner could click through every role before a single real ride was booked.
The next stage is accounts and a shared database, so clients, drivers and owners sign in and see live data, followed by driver onboarding with document checks.
After that comes live flight data, so a delayed landing moves the pickup automatically and tells both the driver and the client, and native apps for the App Store and Google Play.
A ride service earns trust in the moments that go wrong: the seat that has to change hands, the flight that's cancelled, the driver waiting at the airport. SteadyRides is built around those moments, so the product feels as dependable as the people running it.
It also reflects how I work: understand the whole system and everyone in it, then make the hard cases simple.
I design and build products for real businesses, from the first conversation to working software.
Get in touch