Ch5 03: The Startup That Sent Mechanics to Your Driveway — And Rewrote Auto Repair#

Curbee’s founders wanted to build a technology platform for mobile car repair. They had the vision: an app where you tap a button, a technician rolls up to your driveway, and your car gets fixed while you sit inside drinking coffee. Uber for auto repair. The pitch deck was polished. The wireframes were sketched. The tech stack was planned.

Then they did something most Silicon Valley founders would call heresy. They closed the laptops and bought a van.

For the first several months, Curbee ran as a manual service business. No app. No platform. No software. Just a van, a technician, and a phone. Customers called or texted. Someone drove to their location. The repair happened. Payment went through a basic invoicing tool.

By any tech startup yardstick, it was laughably primitive. It was also the smartest thing they could have done.

Here’s what the van phase taught them — lessons that no amount of product design, customer research, or competitive analysis could have produced:

Lesson one: which repairs work on-site and which don’t. The original vision assumed any repair could happen at the customer’s location. Reality disagreed. Some jobs needed a lift. Some required specialized gear that wouldn’t fit in a van. Some were too weather-sensitive for outdoor work. After a few hundred manual jobs, the team had a precise map of what worked mobile and what didn’t — a map that became the backbone of their service menu.

Lesson two: what customers actually value. The founders assumed price was king. It wasn’t. What customers cared about was time — specifically, erasing the hours they would have spent driving to a shop, dropping off the car, arranging a ride home, waiting for a callback, and driving back to retrieve it. The time savings was worth a premium. This insight flipped the pricing model from “cheaper than a shop” to “worth more than a shop because we save you four hours.”

Lesson three: where the real bottlenecks hide. Parts logistics turned out to be the binding constraint — not the repair itself. A technician could swap brake pads in forty-five minutes, but getting the right pads to the right van at the right time could eat a day. The van phase exposed this bottleneck with brutal clarity, and it became the first problem the tech platform was built to solve.

Lesson four: what edge cases look like in the wild. A customer who wasn’t home when the tech arrived. A car jammed in a tight garage. A repair that uncovered a second, nastier issue. A dog that wouldn’t stop barking at the technician. Every one of these popped up during the van phase, and every one shaped the platform’s exception-handling logic.

After several months and several hundred completed jobs, the team knew their business cold. Not from spreadsheets. Not from surveys. From doing the work with their own hands.

Now — and only now — they started building the software.

The product they shipped was nothing like what they would have built on day one. The service menu was carved by real-world feasibility, not theoretical coverage. The scheduling algorithm factored in drive time, parts availability, and job complexity — variables they understood from the trenches. The customer communication flow anticipated the questions customers actually asked, not the ones the founders imagined they’d ask. The pricing model was anchored in willingness-to-pay data from real transactions, not market research guesswork.

The software was lean, focused, and accurate — because every feature was the answer to a question the van phase had surfaced.

This is the progression I’ve watched work in company after company: service first, product second, platform third.

Stage one: manual service. You are the product. You deliver the service by hand. You learn everything — what works, what breaks, what customers love, what they tolerate, what sends them packing. Revenue is capped by the number of people you can hire, but learning is unlimited.

Stage two: software product. You encode the validated service into technology. The software doesn’t invent a new process — it digitizes a proven one. Customers interact with the product instead of with your team. Revenue scales with users, not headcount. Marginal cost trends toward zero.

Stage three: platform. You open your technology to third parties. Other technicians, other providers, other businesses operate on your rails. You become infrastructure. Revenue scales with the ecosystem, not just your own operations.

Each stage stands on the one before it. You can’t build a great product without the understanding that manual service drills into you. You can’t build a great platform without the proven product that earns third-party trust.

Founders who skip stage one — who jump straight to building the product — often ship something technically impressive but commercially adrift. It solves problems customers don’t have. It automates workflows that don’t work. It scales a model that was never validated.

There’s one more asset the van phase generates, and it might be the most valuable of all: data.

Every manual service interaction throws off information. Which repair was requested. What the actual problem turned out to be (often different from the customer’s description). How long it took. What parts were consumed. What went sideways. What the customer said afterward.

This data, stacked up over hundreds of jobs, becomes the training set for the tech platform. The scheduling algorithm is trained on real job durations. Diagnostic suggestions are shaped by real problem-resolution patterns. Customer communication templates are refined by real feedback.

A competitor who launches with software first and tries to gather this data after the fact is fighting uphill. Their dataset is thin, biased (only from customers willing to try an untested product), and lacks the depth that comes from human observation during hands-on service.

Curbee’s data edge didn’t come from superior technology. It came from months of fixing cars in driveways with a wrench.

Guidance#

If you’re building a technology-enabled service, consider starting with the service, not the technology.

1. Deliver the service manually for at least three months. Not as a “beta test” — as a real business. Charge real prices. Serve real customers. Bank real revenue. The manual phase isn’t a dress rehearsal. It is the business.

2. Record everything. Keep a detailed log of every interaction: what was requested, what was delivered, how long it took, what broke, what the customer said. This log is your product spec. It’ll be more accurate than anything you could have drafted in a conference room.

3. Find the bottleneck. After fifty to a hundred manual interactions, you’ll know where the biggest constraint lives. Build your first piece of technology to smash that specific constraint — not to digitize the whole process, but to remove the single biggest chokepoint.

4. Expand tech gradually. Add automation one function at a time, always guided by manual data. Scheduling, then comms, then payments, then diagnostics. Each addition should answer a real problem, not a speculative feature request.

The van comes before the software. The wrench comes before the algorithm. And the understanding you build by doing the work yourself — that’s the asset no competitor can copy.