A feature request hiding a new business.

Everyone agreed. I went to look.

Sales had a large medical-device manufacturer close to the table, and one word kept coming back: multistop. The customer said it. Revenue repeated it. Engineering had already started building it. When everyone agrees that easily on what a customer wants, it is usually worth going to look.

Up to this point in time, Airspace had almost always moved just one order at a time. For most medical-device work that is the right shape: a box or two, dropped on a shelf at a surgery center. Adding a few extra stops to that order sounds like a modest feature, which is exactly why nobody questioned it.

Then I spent a day at their site. They were not moving one order to a few places. They were moving thirty, fifty, sometimes a hundred orders a day across about ten drivers at once, with packages stacked from the floor to above head height. Because the unique nature of Airspace’s business almost always required drivers to move from one stop to the next as quickly as possible, we’d never prioritized or built a way to look across multiple orders in one driver’s possession, or route across them, or bill them. For the first seven years of Airspace the assumption was that the driver should never have to carry more than one order.

The language and the workflows had hinted at it. The site made it plain. They were not asking for a bigger version of what we had. They were asking for something that required new infrastructure.

Keep them moving. Prove the case.

I was taking over the team just as it started building multistop. Telling them the plan would not win the customers it was written for is not a popular first act, and stopping the work was not an option either. Revenue was already selling to a customer we had no product for. So we ran two jobs at once.

The first was keeping that customer moving. We broke the need down by who actually touches the work. Dispatchers needed orders in a driver’s hands before anything else. Drivers needed to see what to move and where it was going. Executives needed a way to judge whether it was working. Within about a month we had revenue and engineering aligned on the smallest honest version of each: our existing driver app showing orders in the sequence they arrived, a tool I built in Bubble so dispatchers could enter orders in order, and a rough analytics cut from the data team. It wasn’t a polished experience, but it was enough to start a pilot.

The second job ran alongside it. A new platform is an expensive thing to be wrong about, so before asking for one we checked whether this was a single customer’s quirk. I worked with our design researcher to map the common shipment types across every sector we served, not only the medical-device accounts sales was chasing: pharmaceutical shipping, consolidations in industrials, and organ procurement, where a team ships several orders at once so one organ can be tested while another travels for transplant.

The pattern was everywhere, and so was the misunderstanding. Customers in every sector asked for multistop. Almost none of them wanted one order with extra stops. They wanted many separate orders carried by one driver, on a route, across a day. The whole company had been hearing the word and anchoring to the obvious expansion on what the system could do. It was a reasonable, but dangerous misunderstanding.

To combat it, we had to act quickly. We framed the insights in a series of diagrams, each describing the “shape” of a customer’s most common Airspace shipments. In diagram after diagram it was clear: users weren’t shipping one order with many stops. They were managing multiple shipments at once.

This approach proved highly persuasive to the revenue team, who could see the insights from our conversations mapped out on paper in a language they now understood. An engineering manager put it bluntly: “If that’s what they need, multistop isn’t going to solve it.”

Aim at a new product. Ship in pieces.

Only then did I set the vision. Not a feature bolted onto an order, but a product we could build up to piece by piece inside the scaffolding Airspace already had. It kept what worked underneath, the order model the company was built on, and put new users in front of a new interface, deliberately detached from the order screens everyone else used.

Building it that way meant we did not have to decide everything at once. If routes proved out with customers, we could productize fully. If they did not, the capability still went to our own operations team, who would benefit from being able to set a route either way.

We envisioned the route itself becoming a first-class object the software understands, and the interface followed. Early sketches imagined stacked, horizontal Trello-like swimlanes; we landed on a vertical route, a long sequence of locations and stops a dispatcher can read at a glance, with drag-and-drop ease and room alongside for the data that governs a real day: locations, order numbers, references, instructions, pictures, and ETAs.

Treating the route as its own unit of work also separated two very different jobs. Dispatchers and drivers manage the whole day, stop by stop; end customers keep the simple order view for the one shipment they care about, and can raise a flag if it drifts off course.

Our revenue org had sized the opportunity across the target manufacturers at nine figures and built warm relationships in the process, so we took the vision to them. One customer was already piloting the stopgap. The other had never piloted anything. Both signed multi-year commitments on the strength of the vision. In year one that came to eight figures in committed business.

The launch that nearly broke it.

Over the next twelve months we rapidly iterated to help our customers solve job after job. Within a few months we’d added a driver map that operators typically kept up on big screens in the office. The map let them see live driver locations and estimate the best routes on their own, then communicate updates to the driver via old-school methods. Within six months we added rough, rudimentary versions of the routing interface, then route optimization, and finally drag-and-drop routing. Along the way we learned more and more about the operators’ daily operations, and iterated to the bare minimum information they needed to manage the day. Gone were street addresses, in were address nicknames. That kind of thing.

By eighteen months the first two customers were happily dispatching on the app and the early builds, the numbers were climbing, and we were moving fast, bringing on bigger and bigger customer sites. We were feeling great and nearly ready to announce wide release out from beta. Then we tried to onboard a much larger site, and realized it wasn’t going to be so easy.

That site moved far more volume than prior sites, so many pickups and deliveries at the same address that the route, drawn as a flat list of individual stops, turned into an unreadable wall. The earlier customers had never hit it; their days didn’t stack duplicates the same way. The model was not wrong. The route was still the right object. What was missing was usability work we had hoped to put off a while longer, starting with the fact that fifteen stops at one address should read as one place, not fifteen. We weren’t a few tweaks from a broad rollout, we’d have to grind this one out.

A feature request that became a business.

Fleet Manager is more than a way to run extra stops. In roughly two years from its first alpha, a single customer request became a validated platform: five of the world’s largest orthopedic and medical-device manufacturers, with the established accounts scaled from practically zero shipping revenue to eight-figure annual volume. Together they represent a nine-figure book of committed revenue we are capturing site by site.

The first two signed on the pitch alone, before the product was fully built. While it was still in alpha and beta we captured about 70% of the value we had forecast. Two more of the industry’s largest manufacturers came on in 2025, each up more than 30% in a year. Across the same span, customers on the platform accounted for close to a third of the healthcare segment’s growth. Underneath it is a sturdier architecture, routes as real objects, with versions, shared locations, ETAs, SOPs, and performance history, so planning gets better today and future services have solid ground to build on.