6 min read
I joined Dan Martell to build Apex — an agentic operating system for founders and SMBs. I‘ve known Dan for over a decade. He built Martell Ventures, wrote Buy Back Your Time, and has more product instinct than most engineers I’ve worked with. The space was white-hot. Everyone and their cousin was shipping AI-powered everything.
We had a working prototype in minutes. Not weeks. Minutes.
Dan isn‘t what you’d traditionally call a technical founder — though he‘d push back on that, and the fact that he’d push back on it is kind of the whole point. Dan was coding. He was prototyping. He was forming opinions about implementation, not just vision. We weren't in the old dynamic where the CEO has the idea and the CTO disappears for six weeks to build it. We were equals.
Sometimes I felt like less than an equal.
That sentence cost me something to write. I‘ve been a CTO for a long time. I drive the architecture. I own the how. That’s my identity. But when the CEO can spin up a working prototype over a weekend using the same AI tools I‘m using, something shifts in a way nobody warned me about. I went from being the builder to being a builder. Dan wasn’t waiting for me anymore. Some days I was catching up to him.
We built Apex with Claude Code. In the rush of zero-to-one — and it was a rush, measured in days, not months — architectural decisions weren‘t really decisions at all. They were reactions. Each choice made in the moment, shaped by whatever feedback Dan had just given me, under the quiet assumption that we’d revisit things later.
We didn't revisit them later.
And I knew — in the way you know something before you can say it — that the thing we‘d built wasn’t what it looked like from the outside. The UI was polished. The happy path worked. We had users. Dan looked at it and saw a product. I saw a movie set. A facade that looks real from the front — load-bearing walls that aren't load-bearing, wiring that runs to nowhere, plumbing that works until someone turns on two faucets at once.
What happened to us is not unusual. It's the new normal.
Peter Thiel drew a line in 2014 and a generation of founders organized their entire identity around it. Zero to one: you make the thing that didn't exist. One to n: you copy and scale. Clean framework. Seductive hierarchy. Zero-to-one was the sacred act — find the secret nobody else sees, build the monopoly before anyone catches on. Everything after that was just execution.
That framework held because building was genuinely hard. A working prototype meant months of engineering. A team. Real money. Getting to “one” meant you‘d already fought through serious technical problems. The prototype wasn’t just a demo — it was proof you'd survived the act of creation. Building was the moat.
That world is gone. What took a team months now takes one person days — sometimes minutes, as Dan and I discovered. And the people doing it aren‘t just engineers. Founders with no technical background are spinning up working prototypes over a weekend. Dan was early. He’s not the exception anymore.
Daniel Noel, a builder I know, put it in a way that stuck with me. He quoted Luke 14 — the parable about counting the cost before building a tower, lest you lay the foundation and can‘t finish. For centuries that was wisdom: plan before you build, because building is expensive. Daniel’s point was that AI flipped the parable. The cost is so low now that we build as preparation. We don‘t count the cost and then build. We build and then count what we’ve got. The prototype isn‘t the commitment anymore. It’s the sketch on the back of the napkin — except the sketch actually runs.
This is good. More people can create more things than ever before. But it creates a problem Thiel's framework has no language for.
When building was hard, reaching “one” meant something. The prototype that took three months and five engineers to produce was battle-tested by the act of its own creation. The team had made real architectural decisions, debugged real problems, thought about real edge cases. Not because they were disciplined. Because the slowness forced them to. You couldn't help but learn the codebase as you built it. You built it line by line.
AI-generated prototypes skip that education. They look the same — maybe better. But the CTO, if they‘re honest — and this is the hard part, being honest — sees what the CEO and the investor don’t. In 2025, METR found that experienced developers using AI tools were 19 percent slower at completing real tasks while believing they were 20 percent faster. A 39-point gap between perception and reality. AI doesn‘t just change what we build. It changes how we feel about what we’ve built. Everything feels more done than it is.
Thiel gave us two categories: create something new (zero to one) or copy and scale what exists (one to n). But there's a phase he never addressed — the treacherous space between creation and scale.
I'm calling it one to two.
At one, the thing exists. It works, more or less. There might be paying customers. Real excitement. But the architecture was born under pressure, the decisions were reactions, and nobody fully understands the codebase — including the AI that wrote most of it.
At two, the product is real. It survives without heroics. A new engineer can onboard. You can ship a feature without fearing something unrelated will break. The CTO can take a vacation.
But one-to-two isn‘t just about code quality. It’s about knowledge.
At zero-to-one, all the knowledge about the product lives in the builder‘s head. You know why every decision was made because you just made it. The codebase makes sense because you just wrote it. You are the world model — the living, breathing understanding of what the product is, how it works, where it’s going.
At one-to-two, the product outgrows your head. The codebase is too large, the decisions too numerous, the context too rich for one brain to hold. The knowledge needs to be externalized — into documentation, tests, issues, monitoring, processes — into systems that survive without you.
The journey from one to two is the journey from a world model in your head to a world model in the system.
That's the thread that connects everything in this book — the technical choices, the team dynamics, the identity shifts, the architecture decisions. Every chapter is some version of the same question: how do you take what only you know and make it real enough that others can build on it?
The distance between one and two is where most startups die. Not because the idea was bad. Not because the market wasn't there. Because the thing that looked like a product was actually a demo, and nobody had a plan for making it real.
Thiel could afford to skip this phase. When your founding team includes the people who would later start YouTube, LinkedIn, Yelp, and Palantir, you don't need a book about the messy middle — you have the team that can handle invention and hardening without breaking stride.
Most founders don‘t have that team. Most CTOs are closer to where I was with Apex: one person, AI tools, a tight deadline, and a co-founder who’s already moved on to the next thing.
In 2014, zero-to-one was the hard part, and Thiel was right to write about it. In 2026, it's the easy part.
This book is for the builder staring at a working prototype, knowing in their bones it's not enough, wondering what comes next.
You built it. Now make it real.