Last-Mile Delivery Platform.

The full business suite a restaurant lives in: every order from kitchen to doorstep, its own riders and the freelance pool, the cash, and the numbers.

• Order lifecycle enforced by a table of legal transitions (draft through kitchen, dispatch and delivery), with cancellation, dispute and refund paths
• Kitchen workflow (pending → cooking → cooked → packed) with realtime status
• In-house fleet management plus a freelancer marketplace with offers, counter-offers and subscription gating
• Live courier tracking with routes on OpenStreetMap (Leaflet)
• Delivery price from real road distance, locked in when the order is created
• Prepaid wallet with Stripe top-ups and billing portal, cash-on-delivery reconciliation, disputes with evidence, and exportable reports
• Sign-up checked against franchise territories (PostGIS), plus the restaurant's own radius zones for its delivery charge, minimum order and delivery time

Hardest part

Money that can't drift. As the platform grew to five apps, the same balance ended up stored in four places that could drift apart, so I redesigned money as a double-entry ledger: every posting needs at least two legs that sum to zero, each leg carries an idempotency key, and a deferred database trigger rejects anything unbalanced. I created that trigger before migrating the old data, so the backfill ran under the same rule as production, and it reconciled to the penny.

React 19 · Vite · TanStack Query · Stripe · Leaflet · PostGIS · Supabase

The lightweight way in, for a restaurant that only wants riders: sign up fast, then book a delivery on one screen in under 30 seconds. No kitchen boards, no fleet to run, no subscription.

• Fast sign-up, self-serve or recruited by the local franchise, with the delivery area checked up front
• Pay per delivery from a prepaid wallet; jobs go to the franchise's freelance riders
• Ready-time keys (“Now” plus the restaurant's own prep presets) instead of any rider-assignment UI; the backend releases the job to riders ahead of the ready time
• Postcode lookup with a map-pin fallback, a saved address book, a live price quote, a distance cap and a wallet-balance check
• Live board and map, a scheduled queue, and a detail view with live rider location and a signed proof-of-delivery photo
• Cancel before pickup, mark the food ready early, or push the ready time back
• Built for arm's-length use on a tablet: state is never shown by colour alone, and touch targets are designed to 46px
• Specified before it was built: I wrote its requirements spec and a 21-decision record, then traced 76 business rules, acceptance criteria and edge cases to code and tests

Hardest part

Realtime that silently lies. Three hand-rolled subscriptions each had their own bugs: a late “closed” signal from an old channel could flash a false “connection lost” banner, and a reconnect never re-fetched what was missed, because realtime replays nothing across a gap. I replaced them with one shared channel hook that resyncs after every gap and reconnects the moment the network returns or the tablet wakes. Submission is idempotent end to end, so a double-tap mid-service can never create two bookings.

React 19 · Vite · TanStack Query · Supabase Realtime · Leaflet · Vitest

What riders carry: go on duty, accept a job, navigate, prove delivery and get paid, and keep confirming pickups and cash when the signal drops.

• Multi-step onboarding with document upload and admin verification
• Pushed delivery offers plus a bid pool, claimed through server-side functions that enforce active-order and cash limits and lock the order first, in one fixed order, so the first claim wins and the other rider gets a clean refusal, never a deadlock
• Pickup → delivered flow with cash collection and photo + GPS + timestamp proof of delivery
• Background GPS tracking via a foreground-service task with batched location pings
• Earnings from the shared ledger, payouts, cash-in-hand, and disputes with evidence and a response deadline

Hardest part

Offline-first correctness: an MMKV-backed action queue with dependency ordering (a cash confirmation auto-fails if its pickup fails) and conflict semantics (network errors pause the queue and retry on the next reconnect, up to 10 times; state conflicts fail immediately), draining on reconnect. Live location survives backgrounding and flaky networks by batching GPS points and re-merging failed batches in timestamp order so the trail never scrambles.

React Native · Expo · Zustand · MMKV · Supabase Realtime · Maestro

A franchise owner's control panel over their whole territory: outlets, riders, orders, billing, payouts and disputes, scoped to only what's theirs.

• Franchise-scoped KPI dashboard
• Outlet/retailer CRUD that provisions the auth user and record, enriched with live order, rider and subscription counts
• 5-step rider onboarding with client-side image compression and private, signed document storage
• Order oversight, plus read-only views of its businesses' subscriptions and its riders' payouts from the shared ledger
• Dispute decisions with a rider response window, and a unified pending-approval queue

Hardest part

Multi-tenant isolation in two layers: a franchise_id on every tenant-owned record (orders, businesses, riders, disputes), guarded by Postgres row-level-security policies, plus a client-side filter so a cross-tenant write returns zero rows and surfaces as an error. Every route checks the account's status, accounts are created on a separate client so they can never replace the owner's session, and each rider gets a password of their own. I took its catalogued defects from 16 to 1.

React 19 · Vite · Supabase (RLS) · Stripe

The platform's command centre: approve franchises, draw the territories that decide which franchise serves each restaurant, and watch the money and the risk.

• Platform-wide KPIs, franchise approval lifecycle, and subscription/MRR oversight
• Per-franchise revenue (GMV, commission, MRR), platform growth analytics, and a disputes & penalties console
• Territory drawing on Google Maps, backed by postcode districts that decide which franchise a restaurant joins, and so who handles every order it books
• Finance view of the ledger with editable rate cards, plus payouts and dispute decisions
• Network explorer with a detail page for every franchise, retailer and courier, and one search across all of them
• Courier-performance alerts with admin-set thresholds, and CSV exports

Hardest part

Deciding which franchise a restaurant belongs to. Territories started as hand-drawn PostGIS polygons with a point-in-polygon lookup; I redesigned them around postcode districts, each unique across the whole platform: the lookup matches by district first and falls back to the drawn shape, and the database refuses overlapping territories, so no address can match two franchises. A restaurant is matched when it signs up, and every order it books belongs to that franchise. On the data side, every page moved to server-side paging with filters kept in the URL, closing 15 of its 16 catalogued defects along the way.

React 19 · TanStack Query + Table · Google Maps · Terra Draw · Supabase · postcodes.io

Rebuilding the backend they share

All five apps run on one Postgres database: a single realtime layer, one money ledger, and a multi-tenant schema locked down with row-level security. As the apps grew, I audited a full dump of the shared database and rebuilt it in place across 156 migrations (a double-entry ledger, a table of legal order transitions, rewritten security policies, private storage and scheduled jobs), adding first, backfilling second, and only dropping what no app still used, without losing a single row. I then squashed the history into a single baseline and proved it identical to the database it replaced: 2,002 database objects, zero differences.

Locking the backend down

As five apps grew on one schema, I audited and hardened the whole backend. Payment secrets live only in server-side functions, behind a hand-verified, idempotent webhook. File storage is private, served through short-lived signed URLs. Admin access is an explicit check, never a default. And 148 row-level-security policies enforce tenant isolation in the database itself; the ones that would otherwise loop back on themselves go through a small set of trusted helper functions.

Hosting and deploys

I moved the platform off managed hosting onto a single hardened server I set up: self-hosted Supabase, every app in its own container behind nginx and Cloudflare, and SSH reachable only over a private network. Every web app ships through the same pipeline: secret scanning, a container build, a push to a registry, and a deploy that checks the running image matches the commit. Database changes are rebuilt from zero on every pull request and only reach production after an automatic backup. Deploys refuse to run against a different Postgres version from the one tested, and the migration tool is pinned to a release that runs each migration in a transaction.

The public website

I also built the marketing site that sells the platform to restaurants and franchise operators and recruits couriers: about 40 statically rendered pages, a lead pipeline that never claims a form was sent when it wasn't, and structured data that only states facts the business has confirmed. When it pinned a CPU core at 100% in production, I traced it with system-level profiling to a known framework bug and shipped a workaround.

My role

I designed and built all five apps, the shared backend (the Postgres schema, the row-level-security policies, the database functions and the realtime architecture), the public website, and the infrastructure it all runs on. I did it largely solo, leading one associate in the final months. I took the client on in Jul 2025 and saw it through to hand-over in Oct 2026. The work is under NDA, so it's described here by function and architecture only, without the client or product names.