← Back to work

Case study 05 · 0-to-1 · Last-mile logistics

Built Track from 0 to 1 - a last-mile delivery product for foodservice

Validated demand by integrating a third-party tool before building anything, then built a purpose-built product for the domain's real complexity: midnight departures, 30–40 stops per driver, and catch-weight products.

4distributor fleets launched
8,000+restaurants served
2,500restaurant enterprise rollout at the largest distributor on Track

How it started

In 2020, COVID shut down restaurants but opened a new channel: direct-to-consumer food delivery. Cut+Dry pivoted to help distributors ship directly to consumers - a new fulfillment model that needed routing, tracking, and delivery notifications. Instead of building from scratch, I integrated Routific, a third-party routing platform, to test whether the value prop held before committing engineering to it.

It did. Distributors wanted delivery visibility; customers wanted ETAs. But Routific was built for generic delivery, not foodservice - it didn't handle midnight truck departures, back-haul stops, catch-weight products, or multi-stop routes with 30–40 drops, and the licensing cost didn't scale. So I scoped and shipped Track with engineering, carrying over the validated value prop while building for the domain's actual complexity.

The pivot that shaped the product

We first built a live map for restaurants to watch their truck - the Uber Eats model applied to foodservice. It flopped. Restaurant managers aren't consumers tracking a burger from the couch; they're running a kitchen. I scrapped the live-tracking screen and reframed the entire product around ETA notifications: tell the restaurant when to expect the truck so they can have someone at the dock, then get out of the way.

What I scoped and launched

The engineering team built; I scoped the product, drove releases, and ran the launches.

Driver app (iOS + Android)

Drove releases v2.0.3 through v2.0.7, each informed by real driver feedback: a "select next stop" override for experienced drivers who know traffic patterns, delivery photo capture with gallery support, at-a-glance stop status icons, odometer and break/lunch logging for compliance, and a downloadable PDF delivery log.

Distributor monitoring portal

A web dashboard showing all active routes with real-time driver positions, per-stop shareable links operations could send to customers, and route file ingestion from distributor ERP systems via daily CSV/file drops.

Customer notifications

Automated SMS and email notifications with ETA windows, tuned against actual route data - one distributor's initial 2-hour windows were too vague to be useful, so we tightened them.

How I launched it

The first customer was the pilot - configuring routes, onboarding drivers, and launching branded customer notifications. The main challenge was driver adoption: drivers are delivering 500-pound pallets of meat at 4 AM, so the app had to be dead simple. The second customer surfaced data-quality and timezone edge cases requiring coordinated fixes across the portal, driver app, and customer-facing surfaces.

The largest enterprise customer was the most complex deployment: 2,500 active restaurants, 6-day-a-week delivery, trucks leaving at midnight. I negotiated route-file timing using an order-completeness matrix (6 AM = 95% completeness on weekdays), rolled out from 3 test drivers to the full fleet, and handled edge cases like back-haul stops and ~60 invalid addresses. During rollout I personally dispatched routes and monitored stops - you can't project-manage a midnight truck departure from a Jira board.

What I learned

Next case
Payment gateway at Sysco LABS (CAKE POS) →