9 min read
Nobody warns you about this part. It‘s not the code that breaks first. It’s the relationship.
I don‘t mean the code is fine — we’ve covered that. I mean that before the architecture collapses, before the SSH tunnels start attacking themselves, something quieter happens. The two people building the thing together stop understanding each other. And neither of them notices. They're moving too fast to check.
Dan and I had known each other for over a decade. We had trust. Real trust — the kind built from years of friendship, shared history, mutual respect. When we started building Apex, I assumed that trust would carry us through the intensity. It had carried us through everything else.
What I didn't account for was the speed.
There was a week — maybe three months in — when Dan described a workflow he wanted for onboarding new clients. He talked through it on a call, quickly, the way he does when he‘s excited. I caught the shape of it. I built it overnight. The next morning I showed him the prototype and he said, “Yeah, that’s close,” and we moved on to the next thing. But over the following weeks, I started getting questions from the team that didn‘t match what I’d built. Small things — a field they expected to be there, a step in the flow I hadn‘t included. When I finally went back to Dan, I realized his original description had included a whole piece I’d mentally filed as tangential. He‘d said it. I’d heard it. I just hadn't understood it as load-bearing. And by then the onboarding flow had been in use for three weeks, shaping how the team thought about the product.
The insidious thing about these misunderstandings is that most of them I still don‘t know about. They got shipped and normalized. The prototype became the product, and whatever I misunderstood became the feature. Nobody circled back, because there was nothing to circle back to — the thing existed, it mostly worked, and we were already three conversations ahead. I sometimes look at parts of Apex and wonder which pieces reflect Dan’s vision, which reflect my interpretation of his vision, and which reflect a misunderstanding that simply hardened into reality.
The old cadence of building a product together had a rhythm:
Talk. Think. Build over weeks. Talk again. Realign. Build again.
Those weeks of building were also weeks of processing. You had time to digest a conversation. Time to realize you'd misunderstood something. Time to come back and say, “Hey, when you said X, did you mean this or that?” I never appreciated this until it was gone: the slowness of building was accidental couples therapy. The pace forced alignment because there was nothing else to do while the code was being written.
AI removed that buffer.
Our new cadence:
Talk. Build today. Talk tomorrow. Build tomorrow. Talk the next day.
Every conversation immediately became code. Dan would describe what he was thinking, and by the next day I'd have a prototype reflecting my understanding of what he said. Next day, another conversation, another prototype. The pace was exhilarating. It felt like building at the speed of thought.
But here‘s what I started noticing. After some calls with Dan, I’d feel a specific anxiety. Not about the tech — the tech part almost felt easy. The anxiety was about whether I‘d actually understood what he was saying. Dan moves fast with his thinking. He’s articulate enough that you can feel like you‘re tracking even when you’re not.
Did I really understand what he meant? Or did I understand what I thought he meant?
There was no time to find out. The next conversation was already happening.
I've started thinking about this as a systems problem. A partnership around a product involves three layers, and each one runs at a different speed.
The first layer is trust. Friendship, shared vision, mutual respect. This layer takes months or years to build. Trust is slow to build and fast to damage. You can spend a decade building it and crack it in a week under pressure.
The second layer is communication. The ongoing process of making sure both people mean the same thing when they say the same words. This layer needs repetition, clarification, and the willingness to say “I'm not sure I understood you.” It operates on a cadence of days to weeks.
The third layer is the build. The code, the product, the prototype. Pre-AI, this ran on a cadence of weeks to months. Now it runs on a cadence of hours.
The third layer now moves faster than the first two can support.
You‘re shipping code that reflects yesterday’s conversation. But you haven‘t confirmed you understood yesterday’s conversation. The build outpaces the communication. The communication outpaces the trust. The gap fills with anxiety, misalignment, and shipped misunderstandings.
The world model concept from Chapter 1 makes this concrete. When two people build together, they each carry a model of the product in their heads. The builder‘s model is about what the code does. The visionary’s model is about what the product should be.
At zero-to-one, these models are close enough — everything is small, two people in a room, a few features. At one-to-two, the models diverge. The visionary‘s model updates with every customer call. The builder’s model updates with every bug fixed and every late-night production fire. Both updating at high speed, from different inputs. The gap grows without either person realizing it.
In the old cadence, the weeks of building were also weeks of model alignment. You‘d check in. Realign. Update each other’s maps. The slowness was the synchronization mechanism.
In the new cadence, there‘s no synchronization. By the time you realize the models have diverged, you’ve shipped three prototypes based on a misunderstanding.
This is what almost happened with Apex. Dan's model was evolving from customer conversations. Mine was evolving from what was breaking in production. We were both right. But our models were drifting apart, and the speed of building meant the drift became code before it could become a conversation.
I‘ve been telling this from my side, but I think about what Dan must have been experiencing too. He’d come off a call with a potential customer, full of energy, full of a new way of framing the product — and he‘d share that with me, the way you share something exciting with someone you trust. And then the next day, there it was in the app. Not quite what he’d meant, but close enough that correcting it would feel like criticizing rather than clarifying. He was probably doing the same math I was: Is this worth slowing down to fix, or do we keep moving? And the momentum always won. Dan wasn‘t being careless with his communication. He was being generous with his trust — assuming I’d understood, because we‘d always understood each other before. The speed didn’t break his communication. It broke the assumption underneath it: that a decade of friendship meant alignment was automatic.
Here‘s a specific thing that kept happening. A feature I’d prototyped at midnight — because I was testing something, exploring a possibility — would linger in the app. Dan or the team would see it and incorporate it into their model of the product. Sales would start referencing it. And I‘d realize that my sketch had become everyone else’s expectation, without any conversation about whether it should exist.
The reverse happened too. Dan would describe a vision for a feature. I‘d build my interpretation of it overnight. My interpretation was close. Maybe 80 percent right. But the 20 percent gap — the part I didn’t quite understand, the nuance I missed — became hardcoded into the product. And because the next conversation was about the next feature, not about checking my understanding of the last one, that 20 percent gap never got closed. It got shipped.
Multiply that by dozens of features over weeks. Two people with meaningfully different models of what the product is. Not because anyone was wrong or careless. Because the speed of building outran the speed of alignment.
At its worst, this cadence can bulldoze not just the product but the relationship itself. When building is fast enough to outrun trust, the partnership that made the product possible can become the thing the product destroys.
I don‘t say this lightly. Dan and I are close friends, and our relationship survived Apex. But I’d be lying if I said the speed didn't strain it. There were moments I felt the ground shifting under me faster than I could adapt — not because Dan was doing anything wrong, but because the pace of AI-assisted building is genuinely unsustainable for the human relationships underneath it.
I think a lot of builders go through this without naming it. They feel the anxiety. They attribute it to normal startup stress, personality differences, “we just need to communicate better.” They don‘t see that the root cause is structural: the build layer is running at a speed the trust and communication layers can’t match.
Dan and I had a decade of friendship before Apex. That trust capital is probably why we survived the compression. If you‘re building with someone you’ve known for six months, the math is worse — less trust to burn, faster to crack.
So what do you do? You don't slow down the build — that speed is the whole point. You slow down the decisions that inform the build. Not with process or ritual, but with small acts of vulnerability that keep the relationship underneath the code from cracking.
I didn't start doing these things in month one. The first three months, I shipped fast and assumed alignment. These practices emerged from the pain of getting it wrong.
Repeat back before building. Before turning a conversation into code, take five minutes to write one paragraph summarizing what you understood. “Here‘s what I think you said. Am I right?” It felt awkward, like admitting I hadn’t been paying attention. But it saved days of building the wrong thing. More importantly, it surfaced the 20 percent I didn't quite understand — the nuance I would have missed and shipped.
Name the anxiety. This one I did inconsistently. Some weeks I was brave about it; other weeks I let momentum carry me past the doubt. “I‘m not sure I got what you meant.” That one sentence. Every time I said it, I felt relief. Every time I didn’t, I felt the gap between our models widen.
Label everything as a sketch. When the default assumption is that everything in the app is permanent, every prototype is a promise. Flip the default — everything is a sketch until explicitly declared otherwise — and the cost of misunderstanding drops dramatically. Dan could look at something I‘d prototyped and say “that’s not what I meant” without it feeling like he was rejecting a finished thing. I'll call this the readiness contract later in the book: sketch, testing, solid, production.
Have conversations that aren‘t about features. This is the one I wish I’d done from the start. Even fifteen minutes a week: “Here‘s my model of where the product is. Here’s what I think is solid and what‘s fragile. Here’s what I‘m worried about. What’s your model?” Not process. A practice of care.
Underneath all of this is the hardest thing to accept: the cadence is new. Nobody has done this before. There‘s no playbook for building a product at AI speed while maintaining a human relationship at human speed. The friction isn’t a sign that the relationship is broken. It‘s a sign that you’re operating at a speed nobody's relationship was designed for.
The compression of trust is a structural problem with a human solution. Slow down the decisions. Name the anxiety. Make sure the relationship that started the product can survive the speed of building it.
Because the relationship came first. It has to last longer than the code.