Multi-vertical delivery platform

The problem

The client operated a food-delivery business in the US Virgin Islands and wanted to expand into three adjacent verticals — parcel delivery, ride-hailing, and a school-meals subscription — plus enter a second market in Cape Verde. The obvious path was to build separate apps for each vertical, but that would mean four codebases to maintain, four fleets of drivers to onboard, and four separate customer relationships in a market with only ~110,000 residents.

The unusual constraint was economic: the total addressable market in each vertical, in each country, was small enough that they couldn't justify a dedicated engineering team per vertical. Whatever they built had to be one platform, not four. But at the same time, each vertical had genuinely different requirements — food delivery needs restaurant queueing and food-safety timers, rideshare needs surge pricing and driver routing, parcel needs proof-of-delivery, and school-meals needs recurring subscriptions and a parent portal.

The approach

We architected the platform around vertical composability from the first commit. Three moves made it work:

1. Unified dispatch engine, vertical overlays

Rather than four dispatch systems, we built one. The dispatch engine handles the universal problem — routing a job from a customer to the nearest available worker — and doesn't know or care what kind of job it is. Each vertical is an overlay: a set of vertical-specific fields on the job payload (food menu items, ride pickup and drop coordinates, parcel dimensions, school-meal subscription ID) plus vertical-specific handlers on the worker app.

The overlay pattern let us ship food delivery first, then add parcel three months later without touching the dispatch core, then add ride-hailing and school-meals another quarter after that.

2. Multi-country from day one, not as an afterthought

The USVI and Cape Verde have different currencies (USD and CVE), different official languages (English and Portuguese), different phone-number formats, different KYC requirements for drivers, and — critically — different regulatory environments for ride-hailing.

We built the currency, locale, and regulatory-config layer into the platform from the first commit, not as a "we'll deal with it when we launch in Cape Verde" TODO. That decision cost about three weeks upfront and saved a rewrite when the Cape Verde launch happened eight months later.

3. Ride-hailing vertical — owned end-to-end

Ride-hailing was the highest-risk vertical because it introduced surge pricing, driver-side navigation, driver background checks, insurance requirements, and real-time trip tracking — none of which the other verticals needed. It was also the vertical most likely to bloat the platform if it wasn't given a clear owner.

I owned it end-to-end: fare engine (base + per-km + per-minute + surge multipliers), driver-side single sign-on with the main platform, the super-admin portal for setting surge zones and vehicle categories, and the trip lifecycle from request → matched → picked up → completed → paid. 164 of the 176 authenticated admin routes for the vertical shipped under my name.

What shipped

• Four verticals live across two countries on a single dispatch engine
• Native iOS and Android apps for both customers and workers
• Real-time driver tracking via Socket.IO
• Currency and language switch per market, transparent to application code
• Ride-hailing fare engine handling surge, wait time, and cancellation fees
• Super-admin portal for platform-wide operations — drivers, promos, disputes, refunds
• Zero-downtime Cape Verde launch after eight months of prep

What made the release own-able

Multi-vertical platforms fail when nobody is responsible for the trade-off between vertical-specific requirements and platform-wide simplicity. Adding a queue-management feature for food delivery costs the rideshare team latency they don't want. Adding surge pricing for rideshare adds complexity to the pricing model that the parcel team doesn't need. The only way to keep the platform from fragmenting is someone who owns the platform's integrity end-to-end — not just each vertical in isolation.

I was that person for the rideshare vertical, which meant I was also the person saying "no" when someone wanted to add a vertical-specific hack to the dispatch core.

Stack details

• Backend: Laravel 5.6+, PHP 7.x, MySQL 8, Redis for real-time state
• Real-time: Socket.IO on an adjacent Node service, session-tunnelled through Laravel
• Frontend: React 19 admin panel; PWA for early customer flow before native app launch
• Native mobile: Swift iOS + Kotlin Android for both customer and worker apps
• Payments: local payment gateways per market
• Notifications: Firebase Cloud Messaging + Twilio SMS
• Infrastructure: EC2 + RDS, custom deploy runbook (later migrated to CI/CD)