Alex Pricopie · AI builder ← All case studies

Case study · Dispatch app · October 2026

A dispatch desk for a chauffeur service, built in 20 hours over 3 days

An outbound agency set seven developers the same 3-day build test for one of its clients. I sent all nine required features two days before the deadline, and the agency chose me.

Dispatch dashboard with live numbers and pickups that need a chauffeur 1 2
Dashboard. 1 Fleet ready changes the moment a car goes to the workshop. 2 Pickups without a chauffeur, the most urgent first.
Assign and dispatch, 10 seconds. One click assigns the best chauffeur, and the trip moves from Offer to Assigned to En route.
Client
US agency, for its chauffeur-service client
My role
Sole builder
Build time
20 hours*
Calendar
3 days, 7–9 Oct 2026
Stack
Next.js, Supabase, Vercel
Status
Build test, chosen by the agency
White-label safe
Yes

* Clock time: my hours plus the hours AI agents worked on their own, rounded down. Waiting time is left out.

The problem

The brief described a dispatch desk for a US luxury chauffeur service. Nine features had to work, or the test was not graded. The status flow (Offer, Assigned, En route, Completed) had to be enforced on the server, and "Only Completed counts as revenue".

The agency's reference app was a front-end with fixed numbers. They wanted every number to come from a real database, on a live URL, usable on a phone.

What I delivered

  • Required: Login, Dashboard, Jobs, Assign driver, Status updates, Drivers, Fleet, Schedule, Documents
  • Extras: all eight stretch goals, including live updates across tabs, an activity log, CSV export, a guided tour and keyboard shortcuts
  • Proof: a test with 100,000 jobs (everyday screens under 1 ms) and 1,000,000 jobs (assigning still under 3 ms)

Three decisions

  1. The business rules are in Postgres, not only in the forms. Status flow, fare limits, seats per vehicle, one trip per chauffeur at a time: they hold for every screen and every direct API call. Send a $21 million backdated job straight to the API and it's refused.
  2. Some rules warn, others block. A short-notice booking is a judgement call, so the dispatcher gets a warning and carries on. Completing a trip before its pickup time is blocked: it would put money in today's revenue that was never earned.
  3. Two dispatchers, two tabs, same job? The second click gets a clear message, and the first assignment stays.

What went wrong

On the last morning, the smoke test I run against production after every merge caught a real bug: a chauffeur still on a late trip was being suggested for the next job, because the app trusted the estimated drop-off time. I changed the rule so a chauffeur stays busy until the trip is marked completed, added a database test for it, and shipped the fix that morning.

Communication

The test had fixed rules: at most one round of written questions, then all six deliverables in a single email. I sent them on 9 October, two days before the deadline: the live app, the repository, a README with costs and known issues, a time log with hours per day, and a 3:30 video of the nine features.

Before sending, I ran two review rounds against the brief (8 and 9 October). The whole build went through 50 merged pull requests. The agency's review call followed on 12 October.

The client

"So far out of all of them, you're just the most creative… You packaged me correctly how I was hoping for, and you have the fastest turnaround time. The other people, they want to charge way too much for like a four-week turnaround… I don't have three weeks. So the main thing for me was speed."

Christian, agency founder · review call, 12 October 2026

Need this under your brand?

White-label, start to finish: I never contact your clients, and I'm happy to sign an NDA. I reply within 2 hours, whatever your time zone.

Contact