How to build a logistics app: scope it right, then ship the three apps inside it

A logistics app is one of those briefs that sounds specific and is not. Under the phrase live at least four products: the last-mile delivery app that gets parcels and food to doors, the freight marketplace that matches shippers with carriers, the fleet operations app that runs a company's own vehicles and drivers, and the warehouse companion that scans, picks and stages. They share vocabulary and almost nothing else: different paying actors, different unit economics, different hardest problems. Projects that start building before naming which one they are ship a shallow slice of all four.

This guide is the scoping and construction manual. It names the four products and their tells, then builds the common case, a delivery operation, from its real structure: three coordinated apps (customer, driver, dispatcher) over one backend, the feature map each actor actually needs, the architecture and the integrations that consume half the budget, the team and phased timeline, the honest cost ranges at offshore rates, and the build-versus-white-label decision that should precede all of it.

It sits in a cluster with its neighbors: the fleet software buyer's guide covers buying the operations layer instead of building it, the platform build guide covers the vehicle-side system in depth, and the shipping API guide covers the carrier integrations a shipping-facing product lives on.

Four products hide under one phrase

Last-mile delivery is the product most people mean: a merchant or consumer books a delivery, a driver picks it up and drops it off, everyone watches the dot move. Its actors are senders, recipients and drivers; its economics are per-drop margins measured in cents, which makes batching, routing efficiency and driver utilization the whole game. Its hardest problems are operational: assignment logic that keeps drivers busy without wrecking promise times, and the proof-of-delivery flow that ends disputes. The consumer-facing gloss sits on top of a scheduling engine, and the scheduling engine is the product.

Freight matching is a marketplace, and marketplaces are their own discipline. Shippers post loads, carriers bid or accept, the platform takes a cut and carries the trust burden: verification of carriers, insurance and documentation, payment escrow, and the dispute machinery for damaged or late freight. Its hardest problem is the cold start, because shippers come only where carriers already are and vice versa, which is why freight marketplaces launch in one lane or one corridor and grind. The app surfaces are comparatively thin; the backend workflow and the operations team behind it are thick.

Fleet and driver operations is the internal-tools version: a company that owns its trucks and employs its drivers wants dispatch, tracking, proof of delivery and driver management for its own operation. There is no marketplace and often no consumer; the buyer is an operations manager, adoption is mandated rather than won, and success is measured in cost per delivery and exceptions caught. This product overlaps heavily with fleet software, and the honest first question is whether to build at all or configure a platform from the buyer's guide and build only the pieces the platform lacks.

The warehouse companion is the fourth and most underestimated: receiving, putaway, picking, staging and handover to drivers, running on scanners or phones inside a building. Its hardest problems are inventory truth and the physical choreography of picking paths, and it lives or dies on integration with whatever inventory or order system the operation already runs. Some builds need it as a module inside a delivery product (the handover between warehouse and driver is where parcels vanish); standalone, it is a different project with a different specialist skill set, and this guide treats it as an integration boundary rather than a chapter.

The four products, told apart

Product	Who pays	Hardest problem	Closest neighbor
Last-mile delivery	Merchants, consumers per drop	Assignment and routing at thin margins	Ride-hailing mechanics
Freight marketplace	Take rate on matched loads	Cold start and trust machinery	Two-sided marketplaces
Fleet operations	The operator, as internal tooling	Adoption and exception workflows	Fleet platforms
Warehouse companion	The operator, per facility	Inventory truth, physical flow	WMS territory

Name yours before writing features. The tell is who pays and what the hardest problem is.

The three apps inside every delivery product

The customer surface is where booking, pricing, tracking and history live, and its center of gravity is the tracking screen: order placed, driver assigned, dot moving, arrival estimate honest. For merchant customers add the batch workflows, daily manifests, CSV and API order injection, and the billing views that finance asks for in week two. The design bar is set by the consumer apps everyone already uses, which is a burden (expectations are high) and a gift (the patterns are settled and nobody wants novelty). The underrated feature is the failure path: what the customer sees when a delivery fails, and how rebooking works, shapes retention more than the happy path does.

The driver app is an operating tool used one-handed, in sunlight, on cheap Android hardware, on unreliable networks, and every one of those conditions is an architectural requirement. The core loop is short: see the task, accept, navigate, arrive, capture proof, next task. Everything else, earnings views, shift management, chat with dispatch, exists to keep that loop running without a phone call. Offline tolerance is the discipline that separates real driver apps from demos: queue the events locally, sync when the network returns, and never block the physical workflow on a spinner, because the parcel changes hands whether or not the POST succeeded.

The dispatcher console is the web application where the operation actually runs: the live map of vehicles and tasks, the assignment queue with manual override (because dispatchers correct the algorithm long before they trust it), exception surfaces for failed deliveries and late routes, and the day-end reconciliation. It is the least glamorous surface and the one that decides adoption, and it is where underbuilt projects die: a beautiful driver app orchestrated through spreadsheets and phone calls is not a product yet. Budget the console as a first-class application, not an admin panel, and design it with the dispatcher's day, not the data model, as the organizing principle.

All three share one backend, and the backend owns four ledgers: orders (the commercial truth: what was promised, to whom, for how much), vehicles and drivers (who and what can fulfill), positions (the live and historical geography), and events (everything that happened, timestamped and attributed). The event ledger deserves the most design attention because every surface reads from it: the customer's tracking timeline, the driver's task history, the dispatcher's exception queue and the analytics are all views over the same event stream. Model events well early, an order was created, assigned, picked up, delivered, failed, each with actor, location and time, and features become projections; model them casually and every feature becomes a migration.

What each surface must do before launch

• Customer: book, price, track, fail gracefullyThe failure and rebooking path shapes retention more than the happy path.
• Driver: the loop works offlineAccept, navigate, arrive, capture proof, next task, all queuing locally when the network drops.
• Dispatcher: live map, override, exceptionsManual assignment override ships day one; dispatchers trust algorithms only after correcting them.
• Backend: the event ledger is designed, not accretedEvery surface is a projection over events; casual event modeling turns features into migrations.
• Proof of delivery ends argumentsPhoto, signature or code, geostamped and timestamped, attached to the order record permanently.

The feature map, by actor and by phase

Phase one features are the ones without which the operation cannot run a single day: order creation and pricing, driver assignment (manual first, assisted later), live tracking, proof of delivery, and the dispatcher's map and queue. Notice what is absent: automated route optimization, dynamic pricing, customer chat, loyalty, analytics dashboards. A single-city operation with a dozen drivers runs fine on manual assignment with a good console, and the discipline of shipping phase one small is what funds phase two with revenue rather than patience.

Phase two features are the ones that convert a working operation into an efficient one: batching and route suggestions (suggestion, not automation, until dispatchers stop overriding), scheduled and recurring orders for merchant accounts, driver earnings and settlement automation, customer notifications tuned past the spam threshold, and the first honest analytics, cost per drop, on-time rate, failure reasons ranked. This is also where the carrier and shipping integrations usually land if the product hands off to third-party networks for coverage the owned fleet lacks.

Phase three is where the product grows edges that match its market: multi-city zoning and pricing, the marketplace mechanics if third-party drivers join, API and webhook surfaces so merchant systems inject orders directly, cash-on-delivery reconciliation in markets where cash persists, and the vehicle-side telematics integration for operators who instrument their fleets, at which point the product borders the territory covered in the fleet platform build guide. Phase three lists are infinite by nature; the roadmap test is whether a feature moves cost per drop, promise reliability or order volume, and everything else waits.

Two cross-cutting features deserve their own line because they are invisible until they are catastrophic. Permissions: merchants must not see other merchants, drivers must not see unassigned customer data, and support staff need scoped views, all of which is cheap on day one and a rewrite on day four hundred. And auditability: who reassigned the order, who edited the price, who marked the failed delivery as delivered, questions that arrive with the first dispute and must be answerable from the event ledger rather than from memory.

Features by actor and phase

	Phase one	Phase two	Phase three
Customer	Book, price, track, POD view	Scheduling, notifications, history	API injection, multi-city, COD
Driver	Task loop, navigation, POD capture	Earnings, shifts, batching	Marketplace onboarding, chat
Dispatcher	Live map, manual assign, exceptions	Route suggestions, analytics	Zoning, third-party handoff
Backend	Event ledger, permissions, audit	Settlement, notification engine	Webhooks, telematics ingestion

Phase one is what the operation cannot run a day without. Everything else earns its slot with operational numbers.

Architecture, and the integrations that consume half the budget

The architecture is a mobile-and-web frontend tier over an API layer over the four ledgers, with one real-time spine running through it: driver positions and order events flow up, assignments and updates flow down, and both the customer's moving dot and the dispatcher's live map are subscriptions to that spine. The technology choices are unexotic, a mainstream backend stack, a relational core with PostGIS or equivalent for the geography, a message or stream layer for events, WebSockets or push for the live surfaces, and the mobile apps built cross-platform unless a specific hardware need says otherwise. Boring choices are correct here; the differentiation lives in the event model and the operational workflows, not the framework.

Maps and routing are the first integration and the first recurring bill. Geocoding (addresses to coordinates, hard in markets with informal addressing), display maps, turn-by-turn handoff for drivers, distance and duration matrices for pricing and assignment, and route optimization when batching arrives, each is a separate product at each provider, priced per thousand calls, and a delivery operation makes a lot of calls. The cost discipline is architectural: cache geocodes permanently, price with matrices rather than repeated directions calls, and meter everything from day one, because map spend that tracks order volume is fine and map spend that tracks bugs is common.

The carrier and payment integrations arrive with the business model. Products that hand off to shipping networks integrate labels, rates, pickups and tracking webhooks per carrier, the terrain the shipping API guide maps in detail, including the aggregator-versus-direct decision. Payments bring the gateway, but also the harder local questions: cash on delivery reconciliation where cash dominates, driver settlement rails, and merchant invoicing with the tax fields finance actually needs. Each integration is two budgets: the build, and the permanent ownership of someone else's API changes, sandbox quirks and downtime, which is why integration-heavy scopes bend toward the higher cost ranges.

If the operation instruments its vehicles, the telematics stream joins the architecture as a second ingestion path: tracker positions, ignition and engine data flowing through the pipeline patterns described in the telematics pipeline guide, reconciled with the driver app's positions (two sources of truth for one vehicle need explicit precedence rules). Most last-mile products launch on phone GPS alone and add hardware only when the fleet is owned and the use cases, fuel, maintenance, driver behavior, justify it; the architecture should leave the socket for that stream even when launch does not fill it.

Terms the build will use daily

Proof of delivery (POD)

Photo, signature or code captured at handover, geostamped and timestamped, permanently attached to the order.

Assignment engine

The logic (manual, assisted or automated) that matches open orders to available drivers under promise-time constraints.

Distance matrix

Batch API returning travel times and distances between many origins and destinations; the pricing and assignment workhorse.

Event ledger

The append-only record of everything that happened to orders, drivers and vehicles; every surface is a view over it.

Cash on delivery (COD)

Payment collected physically at handover; brings driver float, reconciliation and shrinkage workflows with it.

The team and the timeline that survives contact with operations

The MVP team is five to seven people: a backend engineer or two who own the ledgers and the real-time spine, a mobile engineer (cross-platform covering both customer and driver apps), a frontend engineer for the dispatcher console, a designer who has watched dispatchers and drivers work (the qualifier matters more than the portfolio), a QA engineer who tests on cheap Android phones in airplane mode, and a product-minded lead who owns the scope knife. Teams staffed like consumer app projects, heavy on polish, light on operational tooling, build beautiful phase-one demos that cannot run a Tuesday.

The sequence that works runs backend-first: weeks one to four establish the event model, the order and driver ledgers, and the skeleton APIs, because every surface depends on them and event-model rework later is the most expensive rework there is. Weeks four to ten build the driver app and dispatcher console in parallel against the live backend, since those two surfaces plus manual assignment are a runnable operation. The customer surface lands weeks eight to fourteen, and the last third of the schedule belongs to the integrations, maps cost tuning, payments, notifications, and to hardening: offline sync, permission audits, and the load and failure drills.

Somewhere around week ten, run the pilot: real drivers, real orders, one zone, with the team watching. The pilot always teaches the same categories of lesson, addresses that do not geocode, drivers who skip steps the design assumed, dispatchers who need a bulk action nobody specified, network dead zones on real routes, and it is cheaper to learn them in week ten than after launch marketing. Budget two to three weeks of post-pilot correction as a scheduled phase, not as slippage; plans that show a straight line from feature-complete to launch have simply renamed the correction phase to "delay".

Total calendar: four to six months from kickoff to a single-city production launch for a focused scope, with the variance driven almost entirely by integration count and the pilot findings. Marketplace variants run longer because trust machinery (verification, escrow, disputes) is real scope, and multi-region launches add zoning, pricing and sometimes regulatory work per region. The classic overrun causes are scope adjacency (the warehouse module that was "just receiving"), integration surprises, and skipping the pilot, all three of which are decisions, not accidents.

The build, phased

1. FoundationsWeeks one to four

   Event model, ledgers, skeleton APIs, real-time spine

   Done when A scripted order flows create-assign-deliver end to end.

2. Operational coreWeeks four to ten

   Driver app and dispatcher console against live backend

   Done when A real dispatcher runs a staged delivery day without spreadsheets.

3. Customer and moneyWeeks eight to fourteen

   Customer surface, payments, notifications, maps tuning

   Done when A stranger books, pays, tracks and receives without help.

4. Pilot and hardeningWeeks ten to sixteen

   One-zone pilot, offline drills, corrections, audit pass

   Done when Pilot metrics stable; correction list burned down, not deferred.

Sequencing judgment calls

Do this

• Ship manual assignment firstA good console with manual assignment runs a real operation; automation earns trust by matching what dispatchers already do.
• Test on the worst phone you can buyDriver hardware is cheap Android on bad networks; that device is the requirements document.
• Schedule the post-pilot correction phaseThe pilot will find real problems; plans without correction time have renamed it to delay.

Not this

• Build route optimization before the pilotOptimizing a workflow you have not observed automates the wrong assumptions at algorithm prices.
• Treat the console as an admin panelThe dispatcher surface decides adoption; underbuilding it leaves the product orchestrated by phone calls.
• Let map calls go unmeteredPer-call pricing plus a retry bug equals a bill that arrives before the revenue does.

What it costs, honestly

At offshore rates, the focused single-city MVP, three surfaces, manual-first assignment, one payment integration, phone GPS, pilot included, lands between 60,000 and 120,000 dollars, with the position in that range set by integration count and the depth of the merchant-facing features. The same scope at Western onshore rates multiplies by roughly two and a half to four. These numbers assume the scope knife stays sharp; the estimates that ended at triple began as this scope plus a marketplace, plus a warehouse module, plus three regions, approved one adjacency at a time.

The second budget is the one that continues after launch. Recurring platform costs, maps and geocoding, hosting, push and SMS notifications, payment gateway fees, typically run 1,500 to 6,000 dollars monthly for a single-city operation and scale with order volume, with maps usually the largest and most tunable line. The engineering retainer that keeps the product alive, integration maintenance, OS releases, the phase-two backlog, runs realistically at two to four engineers, and operators who budget the build but not the retainer own a product that starts aging the day it launches.

Marketplace and multi-region variants price differently because their scope is different in kind, not just size. The freight marketplace adds verification workflows, document handling, escrow or payment scheduling, dispute machinery and the admin tooling for the operations team that runs trust, commonly 40,000 to 100,000 dollars over the delivery base, and its real cost is the operations staffing beside the software. Multi-region adds zoning, per-region pricing and tax handling, sometimes localization, and the infrastructure work of latency and data residency where regulations care, an increment that varies too widely by region pair for honest generic numbers.

Against these numbers, weigh the configure-first alternative seriously: operators whose need is standard fleet operations rather than a differentiated product often do better buying a platform from the fleet software buyer's guide and building only the thin custom layer on top, and consumer-style delivery startups sometimes launch on white-label stacks (next section) to test demand before building. The build is justified when the workflows are genuinely yours, when per-order platform fees would drown the margin at your volume, or when the software is itself the product you sell.

The budget, in ranges

$60k to 120k Single-city three-surface MVP, offshore Manual-first assignment, one payment rail, phone GPS, pilot included.

$40k to 100k Marketplace machinery increment Verification, escrow, disputes, trust-team tooling on top of the delivery base.

$1.5k to 6k Monthly platform spend, single city Maps, hosting, notifications, gateway fees; maps is the tunable line.

4 to 6 months Kickoff to single-city launch Variance driven by integration count and pilot findings.

Build, white-label, or configure a platform

The white-label route, licensed delivery stacks rebranded as yours, exists because the three-app structure is now a commodity shape, and for some operators it is the right call: launch in weeks, standard flows that already work, hosting and app-store mechanics handled. The costs are structural rather than hidden: per-order or per-driver fees that scale with exactly the number you are trying to grow, a roadmap you influence but do not control, data that lives in someone else's schema, and differentiation limited to logo and palette. It fits demand tests, franchise operations running standard playbooks, and operators whose edge is commercial rather than operational.

The configure-a-platform route fits the fleet-operations product specifically: if your need is dispatch, tracking and POD for an owned fleet, the platforms in the buyer's guide deliver most of it at per-vehicle subscription prices, and the build shrinks to integrations and the workflow pieces the platform lacks. The test is workflow fit: platforms encode mainstream operations, and the further your dispatch logic, customer promises or settlement rules sit from mainstream, the more configuration curdles into workaround, at which point the build case reopens.

The full build is justified by three tests, and honest projects pass at least one loudly. Differentiation: your workflows, promise types or market mechanics are genuinely different, and encoding them is the moat. Economics: at your projected volume, per-order fees exceed the amortized build cost within a planning horizon you believe. Product: the software is what you sell, to other operators or as the platform behind a marketplace, in which case owning it is not optional. Projects that pass none of the three and build anyway are paying six figures for a logo on a commodity.

Whichever route wins, run the decision as a rehearsal of the operation, not a features checklist. Take one real day of your intended operation, the orders, the drivers, the exceptions, the cash if there is cash, and walk it through the candidate: can the white-label stack express your promise types, can the platform's dispatch match your assignment rules, does the build scope actually cover the day. The gaps that surface in rehearsal are the ones that surface in production, and finding them before contracts and kickoffs is the cheapest engineering the project will ever do.

The route decision

What does your operation actually need to own?

• Testing demand, standard flows suffice

  White-label stack

  Weeks to launch; per-order fees are tuition, not overhead, until demand is proven.

• Owned fleet, mainstream dispatch and POD

  Configure a fleet platform

  Per-vehicle subscription beats a build; construct only what the platform lacks.

• Differentiated workflows or software as the product

  Build the three surfaces

  The workflows are the moat; encoding them in someone else's stack forfeits it.

Frequently asked questions

When the delivery product needs a team that has shipped one, AgileTech is a trusted software development company in Vietnam with logistics platforms running in production.