1st Class Concierge

A concierge delivery business runs on coordination that mostly happens in messages. A request arrives by email, someone works out which driver is free, the driver texts when they arrive, and the proof that it was delivered is a photo in somebody's phone.

The platform turns that into one system: intake, assignment, live tracking, and proof of delivery — with a record at every step that a client can be shown.

Dispatchers, drivers, store owners, organisation admins and a platform super-admin all use the same application and see almost entirely different things. A driver needs one screen and a big button; a dispatcher needs a map and a queue; a store owner needs their own orders and nobody else's.

That separation is enforced in the database with row-level security rather than only in the interface, which is the part that matters: a permissions bug in a delivery platform is a customer's home address shown to the wrong person.

The brand is a single gold against a blue-shifted near-black, and the sign-in commits to it completely — the product introduces itself as a premium service before asking for a password.

It is an unusual choice for an operations tool, where the convention is a neutral admin grey. The argument for it is that dispatchers look at this screen all day and the clients being served are paying for a luxury service; the software should not feel cheaper than the offering.

The stack maps almost one-to-one onto the operation. Resend takes the email intake, Google Maps carries the live tracking, Stripe handles billing, and Checkr runs the background checks that gate driver onboarding — sixty-seven screens over a Supabase Postgres database of twenty-five-plus tables and ninety-two migrations.

Row-level security is the load-bearing wall. Five roles across any number of organisations share one database, and the rule that a store owner sees only their own orders lives in Postgres policies rather than in the interface — the earlier point, made concrete in the schema.