Nobody gives you a playbook when you're building something that doesn't exist yet.

There's no Stack Overflow answer for "how do you insure a fleet of cars across hundreds of simultaneous drivers." No design pattern for "how do you transfer someone's seat position, radio presets, and weekend luggage from one vehicle to another while they're sitting at their office desk." You just have to reason from the problem outward, trust your instincts, and build.

That was the reality when Drive Clutch was still a concept on a whiteboard. I was one of two founding engineers on a team of five, building from zero before there was an org chart, a customer, or a proven model. We weren't inheriting a product. We were deciding what the product was.

The Idea Worth Building

The concept started from a simple but uncomfortable truth: car ownership in America is kind of a disaster.

It's the largest wealth transfer most people ever make outside of buying a home, and almost every part of the experience feels like it's working against you. Dealerships with mystery fees. Mechanics you're not sure you can trust. Buying a vehicle optimized for your Tuesday commute and then renting something else for the camping trip. Depreciation before you hit the first intersection. Maintenance schedules that arrive at the worst possible time.

The insight was straightforward: wealthy people don't deal with this. They have a fleet. The right car for the commute, the right one for the mountains, the right one for a night out. The question was whether that model could be built for everyone.

The answer was a vehicle subscription. One monthly membership, access to an entire fleet. Drive an economical car to work every day. Swap into an SUV for the weekend trip. Take the convertible out for your anniversary. No buying, no maintenance, no flat tires. Just drive whatever fits your life right now.

Clean concept. The model was a different story.

You're Not Building an App. You're Building the Operating Model.

Here's the thing about building a new category: your system doesn't just reflect your product decisions. It encodes your assumptions about how the experience is supposed to work in the real world.

Every technical choice we made was a bet. Not because we were chasing novelty, but because there wasn't a known answer to implement.

The backend managed the fleet. Two iOS apps sat on top of it: one for members, one for staff. Members used their app to schedule a vehicle swap, manage their account, and handle anything related to their current car. Staff used theirs to track who needed what vehicle, flag maintenance needs, and coordinate the logistics of the fleet on any given day.

Simple to describe. Genuinely hard to get right.

We also weren't building a normal SaaS app where a failure means someone can't export a report and shrugs. For our members, the product was transportation. If we got it wrong, it didn't just create inconvenience. It could cascade into real life: someone can't pick up their kid, can't get to work, can't get to the airport, can't get home. And because vehicles are physical assets, "failure" could also mean maintenance slips, a mechanical issue shows up at the wrong time, or the system gives the wrong person the wrong access.

We had to design for a much lower tolerance for mistakes, and for operational recovery as a first-class feature, not an afterthought.

The Two Unknowns That Defined the Early Work

There were adjacent models in the world (rental, fleet, leasing) but every one of them is built around the same assumption: one driver, one car. We were trying to build something fundamentally different: a seamless consumer experience across a shared fleet. The hard part wasn't that the problems were unprecedented. The hard part was that they were undocumented.

Two unknowns defined the early work, and neither came with a clean reference implementation.

The first was insurance.

Traditional auto insurance is built around a simple model: one driver, one vehicle, one policy. That model breaks when members can be in any car in the fleet on any given day. We couldn't insure individual driver-vehicle pairs. We needed to insure the experience: the relationship between a member and whatever car they happened to be driving at any moment.

The insurance solution wasn't a clever algorithm. It was policy design and contracts. The important part for this story is simpler: until that model existed, the category couldn't exist.

The second was the flip.

This was the heart of the product experience, and it had to be seamless. Not "reasonably convenient." Actually seamless.

When a member requested a new vehicle, we didn't make them come to us. We went to them. Staff would arrive at the member's location with the new car. They'd transfer everything: belongings from the trunk, personal items from the cabin, and the settings that make a car feel like yours. Seat position. Mirror angles. Radio presets. Climate preferences.

Then they'd hand over the new key and take the old one. The member barely had to look up from their desk.

It felt like magic. And the first time we pulled it off, we knew we had something.

The Moment You Know

There's a specific inflection point in early product development when the idea stops being theoretical and becomes real. For us, it was that first flip.

We watched a member walk out of their office, hand over their old keys, get handed a new set, glance at the waiting SUV loaded with their stuff, and just nod. Like it was obvious. Like it had always worked this way.

That was the signal.

The product worked. What was left was "everything else."

And "everything else" turned out to be enormous: how do you build a fleet acquisition strategy that doesn't bleed you dry? When do you offload a vehicle before depreciation kills the economics? How do you scale staff operations as membership grows? How do you build the routines and recovery paths so the system stays dependable when it's serving real life, not just software?

We had proven the experience. Now we had to prove the business.

From Whiteboard to Proven Business

By the time we reached roughly 100 members, there wasn't much left to prove. We had validated the experience. We had an insurance model that supported it. We understood the economics of fleet acquisition and disposal well enough to know when to buy a vehicle and when to offload it before depreciation ate the margin.

That's the moment the decision was made to go after scale. Not because the team needed reinforcement, but because there were no ambiguities left to resolve. Every meaningful unknown had been eliminated. What the company needed next was execution at a size our small founding team wasn't designed to deliver.

That's when the decision was made to bring in a CEO built for the next phase: scaling fast. The founding team had done what we do best: take an ambiguous idea, turn it into something real, and remove the unknowns until the model could stand on its own. What came next was execution at a size and speed our early structure wasn't designed to deliver, and it was the right moment for the founding team to move on to the next whiteboard problem.

Around two and a half years after that first whiteboard, Drive Clutch sold to Cox Automotive for $220 million.

After the Acquisition

The $220M exit was validating. But what happened next was more interesting.

Drive Clutch didn't get absorbed and shelved. The platform evolved. What started as a consumer subscription app became the infrastructure layer behind vehicle subscriptions across the industry. Clutch's technology ended up powering flexible subscription services for BMW, Mercedes-Benz, and Porsche¹², alongside more than 200 dealer rooftops and nearly 20 OEM brands across the U.S., Canada, and Germany³.

The consumer product became a B2B platform. The user-facing app became a white-label solution other brands deployed under their own names. The fleet management infrastructure we built became the engine for dealer loaner programs, service pickup and delivery operations, and concierge experiences across Cox Automotive's broader ecosystem.

That wasn't a pivot away from the original idea. It was the original idea proving out at a scale nobody initially imagined.

That makes more sense when you consider what these companies already had: dealership networks, maintenance departments, fleet management infrastructure, and decades of operational know-how. A standalone subscription company has to build all of that from scratch. These players already had it. They just needed the software layer on top.

What Building in a New Category Actually Teaches You

Established categories have a built-in advantage: they give you a ceiling to design under. You know roughly what the product needs to do. You know what competitors got wrong. You know what customers expect.

New categories have none of that. You're designing the ceiling while simultaneously trying to figure out if the floor will hold.

A few things I've seen hold true across early-stage builds like this:

• The system has to be honest about what you don't know yet. We didn't overbuild for a fleet of ten thousand vehicles when we were serving a hundred members. But we also didn't make decisions that would have required us to rip the foundation out at two hundred. The goal is reversibility: make the choices that keep your options open, and be deliberate about the ones that close them.
• The experience has to be inarguable before anything else matters. We could have debated stack choices all day. None of it would have mattered if the first flip had felt clunky. In a new category, the experience is your proof of concept. Everything else is noise until that's undeniable.
• Constraint is a design tool. The problems that seemed impossible, like insurance structure and seamless handoff, turned out to be the things that made the product defensible. If the answer had been easy, it would have been easy for everyone.

And perhaps most importantly: the thing you build for consumers might become the infrastructure someone else builds their business on. We didn't design for that outcome. We designed for the experience. The platform's durability is what made the broader application possible.

That handoff wasn't unique to Drive Clutch. The nature of that work meant cycling through this process repeatedly: different industries, different problems, different whiteboards. The job was always the same. Take an ambiguous idea, eliminate every meaningful unknown, and build until you have a proven business instead of a promising one. Then hand it off and start over.

Over about fifteen years working in and around startups, I've been part of close to ten companies. Most of them are still operating. I can't fully explain that. Startups are messy, team-dependent, and subject to forces no individual controls. Luck is real and I won't pretend otherwise.

What I can say is that repeatedly showing up at the zero-to-one stage tends to sharpen a specific set of instincts: knowing which problems are real versus hypothetical, knowing when you have enough signal to move with conviction, knowing what needs to be proven versus what you're just anxious about.

Clutch is one example where those instincts got tested. It wasn't the first. It wasn't the last. The problems are always different. The whiteboard is always blank. That part never gets old.

Resources