From the customer's phone, DoorDash, Uber Eats, Grubhub, and Gopuff look like one app. Under the hood, a last-mile delivery app is actually three coupled products - a consumer app, a courier app, and a merchant panel - wired together with WebSockets, a routing engine, and a payment split. Pato Delivery is our case study of shipping that full ecosystem outside the top-3 national platforms, in a mid-sized city where the national players were weak, slow, and expensive.

This is not a how-to for a generic delivery tutorial. If that is what you need, read our logistics app development guide instead. This post is about the three-surface architecture, the marketplace dynamics, and the engineering tradeoffs we actually made on a production last-mile delivery app with hundreds of partner merchants and thousands of orders in its first months.

The problem: a mid-sized city delivery gap

National food and grocery delivery platforms in the US - DoorDash, Uber Eats, Grubhub, Gopuff - concentrate their product, logistics, and marketing investments in dense urban cores. They reach secondary and tertiary markets by extension, not by design. In those mid-sized cities the economics unravel:

  • Take rates in the delivery category commonly sit in the 15-30% range. For a local restaurant with 8-12% operating margin, that is the entire margin and more. After packaging, marketing fees, and occasional commissions on subtotal plus fees, operators routinely lose money on delivery orders.
  • Couriers earn less per hour than the dense-core average because trips are longer, batch rates are worse, and restaurant wait times eat into active minutes.
  • Merchants get no account manager, no menu photography, and no promotional support - only a dashboard and a takeout bag.

A regional operator who understands the city can carve out space by undercutting the take rate, investing in human merchant onboarding, and giving couriers predictable earnings. That is the wedge. Pato Delivery is what the product looks like when you build it right.

Product concept: three surfaces, three specs

A last-mile delivery app is never one app. It is three apps, each with its own product spec, onboarding flow, failure mode, and release cadence:

  • Customer app - discovery, ordering, real-time tracking, ratings, payment. Ships on iOS and Android. Drives CAC and retention. Must feel as good as DoorDash on day one or it loses the first install.
  • Courier app - shift login, order queue, pickup flow, turn-by-turn navigation, proof of delivery, earnings, payouts. Ships on Android first (courier device mix skews Android) and iOS second. Must be reliable on patchy cellular and cheap phones.
  • Merchant panel - menu CRUD, order intake with audible alerts, prep time controls, payouts, reports. Deliberately built as a web panel running on a counter tablet or laptop - not a mobile app.

Three surfaces means three backlogs. It means a bug in the courier app can degrade customer trust even when the customer app is perfect, because a missed pickup still looks like a failed order on the customer side. Treating these as one product is the first mistake teams make.

Architecture overview

Pato Delivery runs on a single backend serving three React Native clients and one web panel:

  • Mobile clients: React Native for the customer and courier apps, shipped to iOS and Android. Shared component library, separate navigation and state trees.
  • Merchant panel: React web app built for desktop and tablet form factors.
  • Backend: Node.js with PostgreSQL as the system of record for orders, merchants, menus, couriers, and payouts.
  • Real-time tracking: WebSocket channels for live courier location, order status transitions, and merchant order alerts.
  • Routing and geocoding: Google Maps APIs (Directions, Distance Matrix, Places).
  • Payments: payment gateway with split settlement between merchant, courier, and platform.
  • Push: Firebase Cloud Messaging across all three client surfaces.

The event flow for a single order looks like this: customer confirms cart in the customer app -> order lands in Postgres and fires a FCM alert plus a WebSocket event to the merchant panel -> merchant accepts and sets prep time -> dispatcher (automated or manual) assigns the order to an eligible courier over WebSocket -> courier accepts, navigates, picks up, delivers, and hits "delivered" -> Postgres commits the final state -> payment split triggers and the customer gets a receipt plus a rating prompt.

Engineering tradeoffs that actually mattered

Every real last-mile delivery app is a stack of tradeoffs. The five below shaped the product the most.

WebSocket vs long-poll for real-time tracking

At low concurrency, HTTP long-polling every 5-10 seconds is fine and cheap. It becomes a problem somewhere around a few hundred concurrent active orders per city, when your API gateway and your database start serving read-after-read-after-read on location data that rarely changes between polls. WebSockets flip the model: the courier app pushes updates on movement, the backend fans out to the customer app and the merchant panel, and idle connections cost you a socket, not a round-trip.

The tradeoff is operational complexity. WebSockets need a connection manager, reconnect logic on both clients, heartbeats, and a plan for what happens when the socket drops mid-delivery. We started with polling on day one to avoid premature complexity and migrated to WebSocket once concurrent active orders crossed the threshold where polling cost outweighed socket cost. That migration was a sprint of work, not a rewrite.

Google Maps vs Mapbox

Google Maps APIs give you the best-in-class routing and places autocomplete, with the tradeoff of variable cost at scale. Distance Matrix and Directions calls priced at thousands of requests per day start to add up on high-order-volume cities. Mapbox is cheaper per call, gives you more control, and lets you self-host tiles - at the cost of engineering time to build what Google gives you out of the box.

For Pato Delivery we stayed on Google Maps because the app-to-revenue ratio made the bill affordable and the alternative would have added weeks of work on a non-differentiating problem. The rule of thumb: stay on Google until the Maps bill is a top-3 line item in your COGS, then consider Mapbox. Premature optimization on mapping is a classic time sink.

Payment split architecture

There are two places you can split a payment: at the gateway (the gateway charges the customer and splits into merchant, courier, and platform sub-accounts) or at the platform (the gateway sends you the full amount and you reconcile payouts out-of-band).

Gateway-side split is easier on day one - the gateway handles KYC, merchant onboarding, and compliance for sub-accounts. The constraint is that your gateway has to support it (Stripe Connect, Adyen MarketPay, and regional equivalents do) and you eat that gateway's fee structure and sub-account rules. Platform-side split gives you total control and better economics at scale, at the cost of building a ledger, a payout engine, and compliance tooling - closer to building a fintech than a marketplace.

For a marketplace at our scale, gateway-side split was the right call. Our guidance for US marketplace founders building from zero: use Stripe Connect or equivalent on day one. Do not build a ledger until you have an economic reason - and if you need inspiration for when you do, our cashback and loyalty app case study walks through a closely related ledger-correctness problem.

Courier offline tolerance

Couriers lose signal. In apartment basements, in elevators, inside the dead-zone strip mall on the edge of town. A courier app that cannot capture a status transition offline, queue it, and sync it when the radio comes back is a courier app that will generate customer-support tickets every day.

We designed the courier app with a local state machine that accepts pickup, delivery, and proof-of-delivery events offline, stamps them with the device's last known location and monotonic timestamp, and flushes the queue when connectivity returns. The backend accepts out-of-order and late events within a bounded window, validates transitions against the order's current state, and reconciles the timeline. Customer-facing tracking tolerates short gaps gracefully - "last updated 32 seconds ago" instead of "no data".

Merchant web panel vs merchant mobile app

The instinct is to build a merchant mobile app because phones are the ambient compute of 2026. It is the wrong instinct for last-mile delivery. Merchant staff stand at a counter next to a printer and a POS. They need an always-on screen with audible alerts and persistent order queues - not a push notification on a phone that someone has to unlock between tasks.

We built the merchant side as a web panel that runs on a counter tablet or a cheap laptop. Orders play a loud sound when they arrive, stay on the queue until accepted, and print to a receipt printer if one is configured. For high-volume merchants, the web panel is faster, more reliable, and easier to train staff on than any mobile app would have been.

Marketplace dynamics: cold-start for a three-sided network

A three-sided marketplace bootstraps along three curves that move at different speeds:

  • Merchant side is sales-led. You do not acquire restaurants and shops through paid ads - you acquire them with a human walking in, showing the app, and closing. The first 50 merchants take weeks each. The next 250 take days each once you have social proof.
  • Courier side runs on incentives. For the first 6-12 weeks, you overpay couriers via guarantees and sign-on bonuses to guarantee delivery availability during peak hours. You back off the incentives as organic courier supply catches up - and you never fully remove the guarantees, because delivery reliability is your product.
  • Customer side is local marketing plus merchant cross-promotion. Merchants put table tents, QR codes at the register, and receipts pointing to the app. Paid social only starts to work after you have enough merchants for the local feed to feel full.

If you skip any of these and try to flip the network cold with an ad spend, the math does not close. Paid customer acquisition without merchant density gets you installs that uninstall in a week.

Results (verbatim from Pato Delivery)

The launch metrics we can share - and only the ones we can share, without invention:

  • Hundreds of partner merchants in the launch city.
  • Thousands of orders processed in the first months.
  • Average delivery time 30% faster than regional competitors.
  • User satisfaction rate above 90%.

The delivery-time gap is the one that compounds. In a three-sided delivery network, every minute you shave off the customer promise raises conversion, raises reorder rate, and raises your merchant pitch - "orders get out faster with us" is a line that closes sales meetings. That is the flywheel you are building.

What this pattern means for US marketplace founders

Three-surface marketplaces look expensive because they are. A credible last-mile delivery app MVP - customer app, courier app, merchant panel, real-time tracking, payment split, and the backend holding it all together - sits in the $150k-$500k range depending on scope, team, and country of execution. Our app development cost guide and mobile app development process guide walk through the cost and timeline math in detail. Timelines for a first production-ready version land in the 90-180 day range, depending on how lean you are with merchant-side features.

The architecture is non-negotiable. Founders who try to short-circuit the three-surface model - routing couriers through SMS, running merchants off a spreadsheet, or simulating tracking with scheduled polling - will reinvent that decision every sprint until they rebuild the missing surface, now with double the tech debt. The question is not whether to build the courier app. It is when.

If your operating model looks closer to a vertical SaaS than a marketplace - one operator controlling all three surfaces, like a laundry chain or a service-business SMB - the architecture changes materially. Our laundry management app case study covers that pattern. For a B2B marketplace with supplier fan-out and AI-assisted comparison instead of last-mile logistics, the B2B procurement AI case study is the one to read. And if you are still deciding whether you need a full marketplace product or a single-tenant custom build, the custom e-commerce vs marketplace decision guide frames that call. MVP cost discipline matters in every scenario - see our MVP cost and validation guide.

Nearshore execution: how we ship last-mile delivery apps from Brazil

FWC is a Brazilian nearshore development team building production last-mile delivery apps and marketplace products for clients in the US and Latin America. We sit in the same time zones as US clients (Brazil overlaps US Eastern by 1-2 hours depending on daylight saving), we run in English with tight async cadences, and we specialize in the three-surface architecture described above. For US marketplace founders comparing build partners, our Brazilian nearshore app development company guide covers the engagement model, cost bands, and due diligence questions to ask.

CTA: get a scoped estimate for your delivery marketplace

If you are in the early stages of a last-mile delivery app - scoping, pricing, or looking for a team that has shipped the three-surface architecture before - we are happy to walk through it with you.