An early-stage logistics startup: from a dispatch spreadsheet to a live app before the next raise

Discovery ran at the size of the company. There was no audit phase and no workshop — the engagement opened with a scoping session with the founders, built around a single question: what would the MVP have to do to run the real operation and hold up in a room where investors asked to see it work? Priya was running dispatch personally at the time, so how a job actually moved — the call to whichever driver was free, the row updated in the shared spreadsheet, the text a driver remembered to send — was something she described rather than something anyone could look up.

What the session produced was less a feature list than a boundary. The spreadsheet had held at five drivers and was failing at fifteen, and the failures were specific: double-booked pickups, drivers calling in to ask what their next job was, customers with no visibility beyond a text message. Each one pointed at the same small set of pieces — a console that showed who was free, a driver app that told drivers their next job, a tracking link that didn't depend on anyone remembering. What the operation hit every day and what investors needed to see turned out to be the same product, which is why the scope line could be drawn where it was: anything the company wouldn't exercise on a normal day stayed out.

One build decision came straight out of that. Assigning a job and accepting it were one loop, not two separate systems — so a dispatch console without a paired driver app would only have rebuilt the spreadsheet, a record of what Priya had already settled by phone. That is why the driver app and the console shipped together rather than staggered: neither half was testable under real conditions without the other, and the customer tracking link followed inside the same launch window.

The driver app and the customer-facing app were built on a shared React Native codebase. That started as a scoping decision, but it paid out after launch: the fixes made during the first weeks of live dispatch landed in both apps at once instead of being done twice. The local queuing worked out the same way. It was added because drivers ran routes through weak-signal areas, but what it actually did was make a job update on a phone survive a dropped connection anywhere — not only on the routes the team already knew were bad.

None of the objectives asked for it, but the operation came out of the build able to answer questions about itself. The shared spreadsheet was only ever as current as the last person who had a moment to type in it, and it held one thing: where everything stood right now. Putting jobs, drivers, and customers in PostgreSQL behind a single API gave the company one place where that data lived and stayed consistent under concurrent dispatch writes. That reached past dispatch — which driver took which job, and when it was delivered, became something to look up rather than something to reconstruct from Priya's memory.

Two things were left in place for a company that expected to grow. Running the backend on AWS meant the climb from fifteen drivers toward fifty wouldn't mean re-architecting what had just been built — the MVP was lean, but it wasn't a prototype to be thrown away after the raise. The deferred feature requests weren't lost either. Because each one was scoped against the deadline at the demo where it came up rather than quietly dropped, the founders finished the build knowing exactly what had been left out and why. They didn't have that going in.