Safrah — Driver Booking Marketplace for Georgia

Safrah is a driver-booking marketplace for tourism in Georgia. Travellers — most of them arriving from the Gulf — search verified local drivers by airport, dates, vehicle type and spoken languages, agree a price in chat, and book. They pay a small card deposit up front and settle the rest in cash with the driver, day by day, which is how this market actually works.

It is a three-sided product. Customers browse and book; drivers run their own onboarding, documents, availability and earnings; staff approve drivers, arbitrate disputes and manage a wallet ledger. All three sides run in Arabic, English and Georgian, with full right-to-left layout for Arabic — and all three are served by one API that a native Flutter app consumes alongside the web client.

I led the architecture and built it across five months: a Next.js 16 web app on Supabase Postgres where row-level security is the security boundary, a Payload CMS for the marketing surface, and a Flutter client for iOS and Android.

The problem

Getting around Georgia as a visiting family is harder than it should be. Public transport does not go where tourists want to go, ride-hailing thins out fast outside Tbilisi, and the informal market — a driver someone’s cousin recommends on WhatsApp — has no prices you can compare, no accountability and no shared language. Meanwhile there is a real supply of professional local drivers with no way to reach the travellers looking for exactly them.

Safrah exists to make that market legible: verified drivers, transparent per-day pricing, reviews you can read, and a booking you can hold someone to.

Architecture

The web app is Next.js 16 on the App Router with React 19. Supabase provides four things under one vendor — Postgres, Auth, Realtime and Storage — and the decision that shapes everything else is that row-level security in Postgres is the security boundary, not application code. Feature queries run through Drizzle inside a wrapper that switches the connection to the `authenticated` or `anon` role and injects the request’s JWT claims per transaction, so an ownership check is a property of the database rather than something a developer has to remember.

The codebase is feature-sliced. Routing lives in `app/`, business logic in vertical slices under `features/`, generic UI in `components/`, and technical infrastructure in `lib/`. Slices are forbidden from importing each other; when two need the same thing it gets lifted rather than shared sideways. A short list of genuinely cross-cutting slices is sanctioned explicitly — and each entry in that list records the date and the reason it was added, because an architecture rule that quietly erodes is worse than one that was never written down.