In August 2006, Elon Musk published what he called Tesla’s secret master plan. The logic was explicit: build an expensive sports car, use the profits and lessons to build a cheaper sedan, then build something cheaper still. Enter at the high end. Drive down market as fast as possible. When someone buys the Roadster, they are, in Musk’s words, “helping pay for development of the low-cost family car.”
Most people read this as a pricing strategy. Build what wealthy early adopters buy, use the margin to fund the mass market.
That’s true. It’s not the most interesting part.
The Roadster was a probe
The original Roadster had serious problems. The 2-speed transmission failed and was scrapped after about 100 cars - replaced with a single-speed unit. The battery thermal management system wasn’t production-ready. Tesla recalled and repaired hundreds of units in the first year. The car was hand-assembled on a modified Lotus Elise chassis, produced roughly 2,500 in total, and cost $98,000.
None of that was a failure. It was the education.
The Roadster surfaced every problem that mass-producing an EV would eventually require solving. What happens to a lithium battery pack under sustained real-world load? What does thermal management actually need at the margins? What do buyers do with the car that engineers hadn’t anticipated? You can’t answer those questions on a whiteboard. You answer them by building 100 cars, watching what breaks, and carrying those lessons into the next 2,400.
The Model S didn’t happen because the Roadster was profitable. It happened because Tesla knew what the Roadster had gotten wrong. Every engineering decision in the Model S - its own platform from scratch, thermal systems that actually worked, a battery pack designed to be serviced - came from watching the Roadster fail in specific, instructive ways.
The Master Plan wasn’t “build expensive, then build cheap.” It was: build one-off first to discover what production requires, then build at scale.
Files, not a database
I’ve been running a content pipeline on .md files and AI for about three months. Ideas, research, drafts, channel configs - all markdown, organized in a directory, with a set of skills that handle the logic. No real database. The system is inconsistent. Skills don’t always behave the way I expect. The data model shifts as I use it.
I built it this way deliberately.
Not because I can’t build a database. Because I don’t know yet what the database needs to do.
What tables should exist. What queries I’ll actually run. Which relationships are load-bearing and which are coincidental. You can design a data model before you build - every engineer I know has done exactly that, convinced they’d thought it through, and then spent weeks migrating away from the wrong decisions. The things you get wrong show up when you use the system, not when you design it.
The .md files are the Roadster. They’re inconsistent in exactly the way that teaches me what the production architecture needs. Some things want versioning. Some want to be queryable. Some have relationships I hadn’t seen in February. Three months of thermal management failing - of skills misbehaving in specific, informative ways - and I know what the database needs to do. In February, I didn’t.
When I build the real system, I’ll know what I’m building.
Not an MVP
Paul Graham’s “do things that don’t scale” is usually read as advice about customer acquisition - Airbnb going apartment-to-apartment with a camera, Stripe manually signing up their first merchants. Do things by hand until you understand the pattern, then automate.
There’s a version of this for product architecture that gets less attention.
The one-off version isn’t just a way to learn what customers want. It’s a way to discover what the scalable version needs to be. And it’s not the same thing as an MVP.
An MVP is the smallest thing that validates whether demand exists. A concept car is something different: the most ambitious one-off thing you can build to stress-test the technology and surface what production will require. Tesla didn’t build a minimum viable electric car. The Roadster did 0-60 in 3.7 seconds and cost $98,000. It was a stress test with a price tag.
The mistake most engineers make isn’t building one-off. It’s skipping the one-off phase because they’re afraid of building something “wrong.” They go straight to a production architecture before they know what they’re building - and end up with a well-engineered system optimized for a model of the problem that turns out to be incorrect.
The one-off version is how you find out what “correct” means in your specific case.
My .md pipeline will become a real database at some point - when the data model has been stable for a few months and I’ve stopped discovering new relationships. The skills will become deterministic code. The conversation interface will get proper state management.
But not yet. The system is still finding its shape. The thermal management is still failing.
That’s what it’s supposed to do.