7 min readThis chapter is still being written
With Dan and Apex, the handoff wasn‘t dramatic. He didn’t walk away. He shifted. His energy moved from “what should the product be?” to “let‘s go get customers and build this business.” That’s not abandonment. That's his job. The visionary is supposed to sell the vision.
The problem is that the vision he was selling was the product at 0.7. And the product at 0.7 had SSH tunnels attacking themselves and prototypes that had accidentally become promises.
Every partnership between a visionary and a builder goes through this moment. I've started calling it the handoff — the phase transition where attention diverges.
The visionary sees a working product and their brain does what it's supposed to: looks outward. Customers. Revenue. Partnerships. The story. The thing works — now they need to make the world care about it.
The builder sees the same product and their brain does what it‘s supposed to: looks inward. The architecture. The debt. The things that work by accident. They know what the visionary doesn’t — that “working” and “ready” are very different words.
Same partnership. Same product. Same goal. Two people now operating under completely different rules.
No ceremony. No meeting. No documented transition. Just the moment the visionary's attention moves on, and the builder is left holding the thing.
I‘ve lived this. Every builder I know has lived some version of it. The specifics change — sometimes it’s a co-founder, sometimes a client, sometimes your own optimistic self from two weeks ago — but the shape is always the same. Someone declared it done. Someone else knows it isn‘t. And the someone who knows it isn’t is now responsible for making it real.
The handoff isn‘t inevitable — it’s a pattern, not a law. Some visionaries stay technical, one hand on the product while the other reaches outward. Some builders take on the vision because the visionary disappeared and someone had to fill the vacuum. What is a law is that attention diverges. How it diverges varies. What matters is recognizing it when it happens.
The handoff is hardest when it‘s invisible. When nobody names it. When the visionary thinks the builder is just “cleaning up” and the builder thinks the visionary has no idea how much work is left. This misalignment — I’ve come to believe it's the single most common way early-stage companies die.
Let me tell you how it actually played out at Apex.
It‘s late February. Dan is on a streak — three potential enterprise customers in two weeks, each one excited about Apex, each one asking for slightly different things. He’s energized in the way Dan gets when the market is responding: fast messages, forward-looking, already thinking about the story for the next call. Meanwhile, I‘m three days into migrating our staging environment away from production. The config system is still bleeding between environments. The deployment process is me SSHing into a server. I’ve found the world-readable config files and my stomach hasn't unclenched yet.
Dan messages me on a Thursday: “Quick update — where are we on the onboarding improvements?” I look at my week. I've closed nine issues. Staging isolation. Config permissions. A silent failure in the settings sync. Auth endpoints that were wide open. Nine issues, twelve-hour days, and not one of them is visible in the product. The UI looks exactly the same as it did on Monday.
I type back something like “making good progress on the foundation” and immediately feel the inadequacy of that sentence. Dan is selling a product that‘s getting better in ways he can’t see, and I can‘t explain the urgency of what I’m doing without sounding like I‘m making excuses for not shipping features. The health endpoints being open isn’t a story Dan can tell a customer. The staging-production bleed isn't going in a pitch deck. But any one of those problems, left unfixed, could end a customer relationship overnight.
The worst part is the silence between messages. In the early days, Dan and I messaged constantly — product ideas, design questions, “what if we tried this.” During the foundation weeks, my messages are all internal: issue numbers, commit hashes, infrastructure changes. Dan‘s messages are all external: customer feedback, competitor moves, partnership opportunities. We’re both working hard. We're working in different dimensions. And the silence where our conversations used to overlap — that silence is the handoff happening, without either of us naming it.
I start feeling a pull I recognize but don‘t want to admit: the urge to ship something visible just to prove I’m being productive. Not because the product needs it. Because the relationship needs it. I catch myself halfway through prototyping a dashboard feature nobody asked for — something shiny I can screenshot and send to Dan. I stop, delete the branch, and go back to the config permissions. But the pull is real, and I'd be lying if I said I always resist it.
That's the invisible handoff. Not a dramatic fight. Just two people drifting into different cadences, with the silence between them filling up with assumptions neither one checks.
But the invisible handoff isn‘t just about code versus customers. Three weeks in, I’m looking at hardware purchases and COGS — cost of goods sold. Infrastructure costs that will compound with every customer we onboard. And I realize I have no plan. No model. No spreadsheet. Nothing.
For a couple of days I have serious imposter syndrome. Not the usual kind — not “am I smart enough.” The CTO kind: what would a real CTO have done here? A real CTO would have been modeling infrastructure costs from week one. A real CTO would have been thinking about when to hire, who to hire, what the company looks like in three months. I‘ve been so caught up in building — so seduced by the tinkering, by what AI lets me do with my hands — that I’ve neglected the parts of the job that don‘t involve a code editor. Hardware expenses. Hiring decisions. The operational skeleton that a product needs before it has customers, not after. The work I’m not naturally drawn to is quietly becoming the work that could sink us. Three weeks in, and I‘m already wondering if I’m failing the company. Not as a builder. As a CTO.
I've watched the generalized version play out dozens of times. The visionary moves on — customers, deals, the story. The builder starts shoring up the foundation — auth, tests, deployment. All invisible work.
Two weeks later, the visionary checks in. “What's new?” The builder has been working twelve-hour days. But nothing looks different. The UI is the same. No new features. From the outside, it looks like nothing happened.
The visionary starts to worry. The builder feels the pressure. They know the foundation work is critical, but they can't point to anything the visionary can see or sell. So they start cutting corners on the foundation to ship something visible. Now the foundation is half-done, the new features are built on the half-done foundation, and everything is worse than before.
Trust erodes. Not because anyone did anything wrong. Because they were operating on different timelines with different definitions of progress. The visionary measures progress in features and customers. The builder measures progress in stability and architecture. Neither is wrong. Without a shared language, they're both right and completely misaligned.
Start by naming the handoff. Make it explicit. “I‘m going to be heads-down on the foundation for the next three weeks. Nothing will look different from the outside. Here’s what I'm fixing and why it matters.” This conversation takes ten minutes. It saves months of eroding trust.
Before the handoff, agree on what one actually is. Use the framework from the previous chapter. Where are you really? 0.5? 0.7? If you‘re not at one, the handoff isn’t “visionary goes and sells.” It's “both people work together to get to one, then the visionary goes and sells.” Premature handoff is the most common version of this failure.
You need a shared definition of progress. The visionary needs to understand that foundation work is progress, even when it‘s invisible. The builder needs to make the invisible work legible — not by shipping unnecessary features, but by communicating what’s changing and why. A weekly five-minute update: “Here‘s what I fixed. Here’s what‘s more stable. Here’s what I‘m tackling next.” That’s enough.
And name the anxiety when it shows up. If you're not sure you understood your partner, say so before you build the wrong thing overnight. The next chapter is entirely about how AI speed compresses the trust layer underneath the build, and what that costs.
The handoff is going to happen. You can‘t stop it, and you shouldn’t try — the visionary looking outward and the builder looking inward is the partnership working as designed. What you can do is see it coming. Name it. Agree on the new rules before the old ones stop working.
The only thing that kills you is pretending it didn't happen.