8 min readThis chapter is still being written
Every builder at this stage has the same conversation. Maybe not out loud. Maybe it's just the argument running in your head while you stare at the issue board.
The visionary wants features. The product needs foundations. There aren't enough hours for both.
This feels like a tradeoff. I spent months treating it like one. I was wrong.
The conventional framing goes: move fast or be stable, pick one. Ship features or shore up the foundation. Every hour on stability is stolen from growth. Every hour on growth is borrowed from stability. Zero-sum. The builder's classic guilt trip.
Here‘s why that framing is wrong and dangerous: it makes you feel like you’re betraying the product every time you write a test.
Let me show you what actually happens. The Apex data was humbling. Fix-to-feature ratio: 2.93 to 1. For every feature I shipped, nearly three fixes followed. I counted using GitHub issue labels — applied when I created each issue, not retrofitted. It‘s not perfect. But the direction is unambiguous. Seventy-five percent of my time was fixing things, not building them. I wasn’t slow because I was investing in stability. I was slow because I wasn't.
Week 13. Peak fix week. 164 fixes. 43 features. I was working harder than I‘d ever worked. Staying up later. Starting earlier. And advancing slower than at any point in the project. That’s not a tradeoff between velocity and stability. That's instability eating velocity alive from the inside.
The real relationship — and I wish I'd understood this at week 2 instead of week 20 — is that stability is a prerequisite for sustainable velocity. Not a competitor to it.
Everyone nods along when you say stability enables velocity. What I want to convince you of is that the relationship changed when AI entered the picture.
The old intuition: instability is a drag, but a linear one. Ship ten features with shaky foundations, fix thirty bugs. Painful, manageable.
What's different now: AI makes creation fast, but not correct. When you ship the wrong thing at AI speed — and you will, because AI optimizes for the immediate prompt without understanding the broader system — you create bugs at machine speed. The fix spiral that used to take months to become unmanageable now takes weeks.
At Apex, I lived this. The 2.93:1 fix-to-feature ratio wasn‘t just a busy builder’s tax. It was a multiplication effect. AI helped me ship features at a rate I‘d never achieved before — thirty commits a day, sometimes more. But each feature carried the same architectural assumptions the AI had been making since day one: happy-path optimism, no awareness of the broader system, confident code with shallow understanding. The bugs weren’t random. They were systematic — the same classes of failure (silent errors, config conflicts, unhandled concurrency) reproduced at the same rate as the features that created them.
This is the part that makes the velocity-stability question existential rather than merely important. It‘s not that instability is a bigger drag. It’s that instability and velocity are now coupled. The faster you build without stability, the faster you generate the failures that eat your velocity. A 3:1 fix ratio in a world where you ship ten features a week means thirty fixes. In a world where AI helps you ship fifty features a week, it means a hundred and fifty fixes, and you‘re still one person. The ratio doesn’t change. The volume does. And volume is what kills you.
AI acceleration without stability isn‘t velocity — it’s chaos with a tailwind. The acceleration amplifies whatever's underneath. If the foundation is solid, AI makes you genuinely fast. If the foundation is cracked, AI makes you fast at breaking things.
The foundation work — tests, pipeline, observability — isn‘t a tax on velocity. It’s the thing that determines whether AI acceleration works for you or against you. The math is not complicated. We just don't want to believe it because writing tests is less fun than shipping features.
The hard part isn‘t understanding this. It’s acting on it. And here's the uncomfortable version of this chapter: sometimes the builder is the one over-prioritizing features.
We tell ourselves the pressure always comes from the visionary. But I've caught myself pushing features over foundation for reasons that had nothing to do with Dan. A competitor launching something similar. A big prospect who needed one more integration. Fear, basically. The same fear the visionary feels, wearing a different costume.
At Apex, there was a week in February where a competitor launched a feature we‘d been planning. Nobody asked me to rush. Dan mentioned it in passing — “interesting, they shipped X” — and moved on. But I panicked internally. I spent the next five days building our version, skipping tests, deploying straight to production, telling myself the foundation work could wait because “we need to be competitive.” Dan never asked for that sprint. The market didn’t demand it. I manufactured the urgency myself because building felt like progress and the foundation work felt like standing still. The competitor's feature turned out to be half-baked. Our rushed version had two bugs that took a week to fix. The foundation work I skipped? Still waiting when I came up for air.
How do you know if you‘re the one making the wrong call? Here’s my diagnostic: if you‘re skipping your own standards — merging without tests, deploying without review, telling yourself you’ll come back and clean it up “next week” — and the visionary didn‘t ask you to, that’s you. If the pressure to cut corners is coming from inside the house, no conversation with the visionary will fix it. You have to have that conversation with yourself. And it‘s harder, because you can’t pull up a chart and say “look at the fix ratio” to your own reflection. You already know the fix ratio. You‘re choosing to ignore it. The first step is admitting that the builder can be the visionary’s worst enabler — or their own.
Whether the pressure is external or internal, the solution runs through the same place: a shared understanding of what‘s actually happening in the codebase. Which means the most important thing in this chapter isn’t a framework or a ratio. It's a conversation.
The visionary measures progress in features and customers. Visible things. Two weeks of invisible foundation work? To them, that‘s not progress. That might be a problem. “What have you been doing?” is the question you’ll hear, or worse, the one they're thinking but not asking.
Not a vague appeal to “technical debt” — visionaries have heard that phrase so many times it‘s lost all meaning. You need specific language, tied to specific data. Here’s the version I've used, almost word for word:
“I want to show you something. Right now, for every feature I ship, I spend three times as long fixing what breaks. That means 75% of my engineering time — the time you‘re paying for — is going to cleanup, not progress. That ratio is going to get worse, not better, unless I invest in the foundation. Here’s what I‘m proposing: for the next two weeks, I’m going to dedicate real time to tests, deployment pipeline, and monitoring. During those two weeks, feature output will slow down. It will feel like we‘re stalling. Here’s what happens after: that 3-to-1 fix ratio starts dropping. When it hits 1-to-1, I‘m twice as fast as I am today. When it drops below that, and it will, every week is faster than the last. I’m not asking for permission to go dark. I‘ll show you the ratio every week. You’ll see it move. And if it doesn‘t move, we’ll change course. But right now, the fastest path to the features you want runs through the foundation work I'm describing.”
Notice what it does: a metric they can watch, a timeline they can hold you to, a promise they care about, and an escape clause. You‘re not asking them to trust your technical judgment on faith. You’re giving them a way to verify it.
I‘ve given this speech three times. Small sample. But it has never not worked — when backed by real data. The “when backed by real data” part is load-bearing. If you don’t have your fix ratio, go get it before you have this conversation.
Once you‘ve had the conversation, you need a sustainable practice. “Invest in the foundation” sounds noble; “do nothing visible for two weeks” sounds terrifying. Here’s how to do both.
Maintain a floor of foundation work every week. At Apex, the ratio that finally started bending the fix curve was roughly 70% features, 30% foundation. I don‘t offer that as a universal prescription — your number depends on how much debt you’re carrying. If you‘re drowning in fixes, you might need 50/50 for a month. If your foundation is solid and you’re in a market sprint, maybe 90/10 is right for a while. The principle is this: some nonzero percentage of every week goes to foundation, always. It never drops to zero. The moment it drops to zero, the fix ratio starts climbing again, and you won‘t notice for three weeks, and by then you’ve lost a month. Track the ratio. When I held the line at 70/30, the fix-per-feature number started dropping within two weeks. When I let it slide — and I did, under pressure, more than once — the number climbed back. The data was unambiguous. Find your own floor and defend it.
Look for foundation work that enables features. Not all foundation work is invisible. Refactoring the auth module so it supports the SSO feature the visionary wants — that's foundation and feature. These two-for-ones exist more often than you think.
And make the foundation visible where you can. Dashboards. Status pages. Uptime monitors. Foundation work that the visionary can see and that customers notice. “We now have 99.9% uptime” is a feature, even if the work that got you there was all infrastructure.
The velocity-stability tension is, at its core, a world model problem. The builder sees technical debt accumulating. The visionary sees market opportunity slipping. Both pictures are correct. The tension comes from each person optimizing for their own view without seeing the other.
When both of you operate from a shared understanding — when the visionary understands the fix ratio and the builder understands the market window — the conversation transforms. No more tension. Collaboration. “Given what we know about the technical state and the market, what‘s the highest-leverage thing this week?” That’s a question two aligned people ask. It‘s completely different from “why aren’t features shipping faster?”
At two, velocity and stability aren‘t in opposition. They’re in equilibrium. You ship on Tuesday and you don‘t worry on Wednesday. That’s the feeling. I didn't believe it was possible until I felt it.