Chapter 13: The Builder at One vs. the Builder at Two

Two months into Apex, I‘m at Jayson Gaignard’s Mastermind Talks. Invitation-only. High-end entrepreneur community. The kind of room where people introduce themselves by what they‘ve built, not what they do. Dan Martell has real weight in this world. He wrote Buy Back Your Time. He’s coached hundreds of SaaS founders. When I mention I‘ve joined Dan’s venture studio, people's eyes change. Not because of me. Because of him.

I‘m basking. I’ll admit it. For a few days I get to walk around as “Dan Martell‘s CTO” and that phrase carries currency I didn’t earn. It feels good in a way that should tell me something. I'm not listening yet.

The event ends. I‘m at the airport and I run into Christoph — a fellow AI expert I’ve met at the event. We‘ve hit it off. One of those connections where ten minutes in you’re past the small talk and into real things. We sit down together, and he asks what I‘m working on. I tell him I’ve joined Dan Martell‘s venture studio. We’re building Apex.

He nods. “Oh — is he going to rope you into his Apex thing?”

He laughs when he says it. Casual. The way you‘d laugh about a friend’s side project.

And this is a guy I‘ve just spent two days connecting with. A fellow AI builder. Someone who understands the work. And even he has Apex filed as something Dan is doing. Not something someone built. Two months of my life. Hundreds of commits. Architecture decisions at 3am. A product with paying users. And to my new friend — my sharp, technically literate new friend — I’m invisible in my own story.

So I tell him. “I actually built the damn thing.”

Sweet moment. Maybe my favorite moment of the whole Apex journey. Watching Christoph recalibrate is worth the entire trip.

But on the flight home, what stays with me isn‘t the sweetness. It’s the speed. Two months. We‘ve been building Apex for two months, and an AI expert at an airport gate already has opinions about it. Already has a narrative. Already has it filed under “Dan’s thing.” The world has formed a perception of what we're building faster than I can form the architecture underneath it.

And the perception doesn't include me.

At one, you are the person who builds.

At two, you are the person who makes sure things get built right.

This sounds like a promotion. It feels like a loss. I want to sit with that for a second because nobody told me, and I wish someone had.

The builder at one. I‘m in the code every day. Claude Code open in four tabs — sometimes five if I’m feeling reckless. Issues flying. I‘m prototyping something, shipping something else, fixing a third thing, going back to the prototype. The feedback loop is so tight it’s almost telepathic: I think it, I build it, I watch it work. There‘s a flow state to solo building with AI that I’ve never experienced with any other way of working. Not with a team. Not with pair programming. Not in any previous era of my career. You are the architect and the engineer and the QA and the ops team. Every decision is instant because every decision-maker is you.

I loved it. I need to say that clearly. I loved it.

Any analogy undersells it. It‘s closer to disappearing. Hours evaporate. You look up and it’s dark outside and the feature works and the tests pass and you have that specific satisfaction that comes from making something exist that didn't exist this morning. The loneliness of solo building is real, but so is the sovereignty. You answer to the product and to yourself, and when those two are aligned, building alone is the purest version of the work.

That purity is what makes the next part so hard.

Now the builder at two. Still technical. Still understand the code — probably better than anyone. But spending less time in the code and more time on the code. What gets built. How it fits together. Reviewing someone else‘s work. Thinking at higher altitude when what I want is to be down in the weeds with my hands dirty. The pipeline is running. The observability layer shows what’s happening. The shared understanding of the product is externalized. I hired someone. They're good.

And my job is to tend that shared understanding. Keep it accurate. Keep it aligned — the builder‘s picture, the visionary’s picture, the product‘s reality, all pointing the same direction. Step in on the hard problems. Step back on the routine ones. It’s important work. I know that intellectually.

But here's what it feels like on a specific Thursday in March.

I‘m three hours into a flow state. Deep in the notification pipeline — the kind of bug that lives at the intersection of three systems, where the timing has to be exactly right or messages get dropped. This is my favorite kind of problem. Intricate. Technical. The kind of thing where you hold the whole system state in your head and manipulate it like a puzzle. I’m close to fixing it. I can feel the shape of the solution.

Meanwhile, there‘s an architectural decision that needs to be made about how the product will handle multi-tenancy going forward. My hire flagged it Monday. I said “let me think about it” and then haven’t thought about it because I'm in the code. The multi-tenancy question will affect every feature we build for the next six months. The notification bug affects maybe forty customers during a specific edge case on Tuesday evenings.

I spend Thursday on the notification bug. I fix it. It feels great. And the multi-tenancy decision sits for another week, which means my hire is building a feature on top of assumptions that might be wrong, which means we'll potentially rework two weeks of their output once I finally engage with the architecture.

Which is exactly what happens. When I finally sit down with the multi-tenancy decision the following Wednesday, we choose a different isolation model than what my hire assumed. Two and a half weeks of their feature work has to be partially rewritten — not scrapped, but significantly reworked to fit the new boundaries. They handle it gracefully. But the rework costs us ten days we don't have, and the root cause is a Thursday I spent chasing dopamine instead of doing my actual job.

That's the cost. Not in the abstract — that specific Thursday, that specific month of consequences. I chose the thing that gave me flow over the thing that gave the product direction. I chose being a builder at one when my job was to be a builder at two.

The identity crisis hits here, and it hits in a specific way. It‘s not just that you’re doing less building. It‘s that the building you should be doing is different in kind. Architecture. Interfaces between systems. Decisions about what not to build. Review. Direction. The work that makes someone else’s building effective. None of that gives you the same dopamine as writing code that works. None of it produces that clean, green-tests, shipped-to-production satisfaction. The feedback loops are longer, fuzzier, and you can't always tell if what you did today mattered until weeks later.

I felt this at Apex acutely. The joy of working alone with the AI was real. No negotiating priorities. No coordinating schedules. No explaining decisions I‘d already made and was confident about. Just me and the machine and the product getting better every day. Moving to a world with communication overhead, documentation requirements, onboarding someone — that felt like a downgrade. Like I’d traded a sports car for a minivan.

The minivan wasn't a metaphor for long.

Six weeks into Apex — six weeks — we‘ve started onboarding our first real customers, and we have Hunter — young, energetic, all-in — as the face of that process. But these customers aren’t just learning how to use Apex. They‘re learning what Apex is. What building with AI even looks like. We’re onboarding people into a category that barely exists yet, using a product still finding its shape.

Out of the first three onboardings, one goes well. Out of the next five, maybe two. The rest are broken in ways that compound. API key configuration is a maze. Updates fail. Maintenance is manual. And even when the system is up and running, customers use it in ways we haven't anticipated — building up their context until sessions bloat and the LLMs get dumber the longer they run. Configuring channels is its own disaster. OAuth is not your friend. It was never your friend.

Poor Hunter. Three weeks of being the face of a product that keeps letting people down. He has the energy for it. Energy doesn't fix API keys.

I‘m driving back from a fly fishing trip with my son Jacques — spring break on the Snake River in Jackson, Wyoming, Kath and the girls in Cancun — when Marcel calls. Marcel runs all the Martell Ventures portfolio companies and has stepped in as product lead for Apex. He isn’t just managing it from a distance — he's an avid user. His Apex is named Phil. He knows the product from the inside, which means he knows exactly how bad things are.

Long conversation on that drive. Marcel lays it out: the first round of customers are unhappy. Not frustrated-but-patient. Unhappy. And Hunter is absorbing all of it.

Somewhere on that Wyoming highway, with the Tetons in the rearview, I stop arguing with myself. This is where the CTO stops building and starts answering for what he built. Not delegates it. Not optimizes it. Owns it.

I want to hide behind Hunter. Trust me. Let the guy with the youthful exuberance be the buffer between me and the minefield. But I know — in that body-before-brain way — that a values-based decision means stepping in front of the firing squad myself.

So I become the first line of customer support. Me. The CTO. The person who would rather be four tabs deep in Claude Code than reading another Slack message that starts with “Hey, so…”

I dread opening Slack in the mornings. Physically dread it. The Apex channels are a catalogue of everything that isn‘t working, written by people we’ve made promises to. API keys misconfigured. Updates that break things. Sessions that degrade. OAuth flows that make people want to throw their laptops. And underneath all of it, the basic truth that the app has real problems, and the only person who can look a customer in the eye and say “I know, and I'm fixing it” is the person who built it.

That‘s the part I don’t expect. Stepping in doesn‘t just help the customers — though it does. It helps Hunter. Once I’m absorbing the fire, Hunter can stop being a shield and start being what he‘s actually good at: onboarding. He starts running building sessions with each new customer, sitting with them, helping them stay focused on what Apex can actually do instead of what’s broken. He goes from damage control to enablement. The system gets better — not because I write better code that week, but because I put myself in the right seat.

Those weeks — navigating the minefield of unhappiness, as I start calling it in my head — are the furthest from “builder” I've ever felt. No flow state. No green tests. No satisfaction of making something exist. Just the slow, grinding, deeply human work of keeping people from giving up on something I believe in.

And here‘s the fear that lived underneath all of it, the one I didn’t say out loud for months: is this the beginning of the slide? You hire one person, then two, then five, and one day you realize you haven‘t written code in six months and you’ve become the thing you swore you'd never become. A manager. Not a builder.

The fear is partly justified. The slide is real — I‘ve seen it. But it’s not inevitable. Here‘s how you tell the difference: if your non-building time goes to architecture — system design, technical decisions that shape the product — you’re still a builder. You‘re building at a different altitude. If your non-building time goes to process — scheduling, performance reviews, “how do we structure our standups” — that’s the slide. At two, your team is two people. You don't need a standup. You need a five-minute conversation about what matters this week.

The slide happens when founders confuse growing a team with adopting the rituals of larger teams. At two, stay in the craft.

Here‘s what I had to learn, and I’m still learning it: the communication isn‘t bureaucracy. It’s the world model.

All that overhead, all that documentation, all that process — it‘s externalizing what’s in your head into something that survives without you. That‘s the whole game. That’s been the whole game since Chapter 1. The knowledge can‘t live only in your skull. When you explain a decision to your new hire, that’s not overhead. That‘s the product’s understanding getting more durable. When you write up why the auth module works the way it does, that‘s not busywork. That’s institutional knowledge that used to die when you closed your laptop.

Block‘s paper on the player-coach concept landed for me. Someone who still builds but also develops people, sets architectural direction, makes the people around them better. But at two, the metaphor needs stretching. You’re not managing a team. You have a partnership. What‘s actually happening is closer to pair programming at the architectural level. You’re both building. But one of you holds the system-wide context — how the pieces connect, where the product is going, why certain technical bets were made months ago.

And then there‘s the third member Block never anticipated: the AI. The working arrangement at two isn’t player-coach. It‘s architect-builder-machine. You own the architecture and the hard problems. Your hire owns feature execution. The AI handles volume — routine code generation, test scaffolding, boilerplate. Each amplifies the others. This triangle is the actual shape of the team at two in this era. It’s not in any management book because it didn't exist three years ago.

And the landscape is shifting underneath this transition in ways that make the identity question even more acute. Base44, a solo-founder product, sold to Wix for $80 million six months after launch. Medvi, a one-person AI telehealth company, posted $401 million in first-year sales. Dario Amodei predicted with 70-80% confidence that 2026 would see the first billion-dollar company with a single human employee. The solo builder isn‘t just a scrappy underdog anymore — solo builders are producing outcomes that used to require fifty-person engineering teams. Which makes the choice to stop being solo, to bring in a hire, to shift from builder to architect, feel even more loaded. If one person can do this much, why change what’s working?

Because what‘s working won’t keep working. The solo builder at scale is the solo builder at breaking point. The question isn‘t whether you can build a billion-dollar product alone. It’s whether you can sustain it alone. And the answer, past one, is no.

The ratio shifts. From 90% building to something like 50/50. And that 50% of non-building work doesn‘t give me flow. It gives me architecture reviews. It gives me “can we sync on this?” It gives me long walks thinking about system design without writing a single line of code. Some days it gives me the sinking feeling that I’m becoming less useful, even as the product is getting better.

That sinking feeling is the signal that you‘re doing it right. If it felt natural, you’d probably still be hoarding the keyboard.

I keep coming back to that Thursday. The notification bug versus the multi-tenancy decision. I chose wrong, and I chose wrong because the bug felt like building and the architecture felt like talking. But the architecture was building — building at the layer that mattered most that week. I just couldn't feel it in my body the way I could feel the satisfaction of fixing a concrete bug with a concrete solution and a green test suite.

The builder at one has a clean identity. I build things. Simple. Powerful. True.

The builder at two has a complicated identity. I build some things, direct others, think about things that haven't been built yet, review things someone else built, and spend a disorienting amount of time in conversations about decisions instead of making them alone in a code editor.

That complicated identity is what the product needs. What the product needs and what feels good to the builder are, at this transition, often different things. And the work of becoming a builder at two is the work of accepting that.

Because here's the truth I circled for months before I could say it straight: your love of building alone is a preference, not a virtue.

“I‘m just more productive solo.” “Communication is overhead.” “I move faster without consensus.” All true. All irrelevant. The product outgrew solo building somewhere around 0.7. Everything since then has been me doing two jobs poorly instead of one job well. The preference for solo building wasn’t making the product better. It was making me feel better while the product waited.

If you're the kind of person who built something alone with an AI, your love of solo building is probably the deepest professional identity you have. This chapter is telling you that the identity has to stretch. Not break. Not die. Stretch.

Daniel Noel described something that made me sit up straight. He said the brain reward for seeing something in your mind come into reality is now more addicting than scrolling social media or playing difficult games. Building has become a leisure activity. His devs unwind at the end of the day by building side projects. Daniel himself replaced gaming with building a custom game engine — for fun. And when building is that rewarding, the identity question gets even harder: you‘re not just asking the builder to shift from coding to architecture. You’re asking them to shift away from the most satisfying activity available to them. Daniel‘s response was to evolve into something like a chairman — “I POC an idea, get the workflows and process in place, and then get people doing the work.” He found people to run each project so he could operate at the level of ideas and structure rather than implementation. That’s one version of the builder-at-two identity. It‘s not the only version, and it only works if you have people you trust to carry the build. But it’s an honest picture of where this goes when one person has more viable products than hours in the day.

When do you let go of the keyboard? I don‘t have a clean answer. But signals: you’re the bottleneck and you can feel it. The mental map of the system is leaking — things are falling through cracks. Hard problems are getting crowded out by routine work because the routine work is nobody else‘s job. You’re choosing the notification bug over the architectural decision because one gives you flow and the other gives you anxiety.

There‘s a version of this transition that doesn’t work, and I‘ve watched people do it: the builder who stops building entirely and becomes a pure manager. At two, the team is too small for that. You still take the hard problems. You still write the gnarly code. You still spend time in the codebase every day. You delegate the routine, not the craft. You’re the person who does the things only you can do, and you let someone else — a human, an AI, or both — do the rest.

One more thing and it‘s the one that surprised me most. At two, the AI’s role shifts. At one, it was my partner. My collaborator. The thing I talked to more than any human during working hours. At two, I have a human collaborator who brings judgment, institutional memory, the ability to push back and say “that's a bad idea” and have it mean something because they have skin in the game. For routine work — code generation, test scaffolding, boilerplate — the AI becomes infrastructure. Still essential, but no longer the primary relationship.

For the hard problems, though — the architectural decisions, the novel bugs, the design questions that don‘t have obvious answers — I still reach for the AI as a thinking partner. Not because my hire can’t think. Because sometimes I need to work through a problem at 11pm without bothering a human, or explore three architectural options in an hour before bringing a recommendation to the team. The AI didn‘t stop being a partner at two. It stopped being the only partner. And that made all the difference — because the thing I actually needed wasn’t a better model. It was another person.