To Ashley Fieglein Johnson; venerable and adored.

The essay “Building Something New” maps the territory of company creation with all its contradictions – patterns that usually hold, except when they don’t. Principles that often apply, except when violating them works better. Mathematics that generally governs, except when exceptions prove more instructive than rules. That essay reveals the fundamental uncertainty at the heart of building companies. But uncertainty doesn’t mean we’re helpless. While we can’t eliminate the contradictions, we can choose how we navigate them. And if you examine the companies that sustain success over decades – not just survive the early chaos but actually thrive long-term – a different set of patterns emerges. Not rules that always work, but approaches that preserve both the builder and what they’re building. Not a guaranteed path, but a philosophy that treats sustainability as strategy rather than limitation. What follows isn’t a refutation of those brutal realities but a framework for working within them. Because knowing that ninety percent of startups fail doesn’t tell you how to be in the ten percent. Understanding that principles have exceptions doesn’t tell you when to follow them and when to break them. Recognizing that success often requires sacrifice doesn’t mean accepting that sacrifice must define the journey. There’s another way to read the data, another way to do the math. Not easier, but more sustainable. Not faster, but farther. Let me show you what I mean.

i. False dichotomy of suffering
The startup world presents suffering as a credential. Every founder story includes the obligatory tribulations – the destroyed relationships, the health crises, the near-death experiences that somehow led to triumph. We’ve internalized this narrative so completely that founders often create the very suffering they’ve been taught to expect. But when you actually analyze companies that sustain success over decades rather than years, you notice something curious: their founders rarely have these dramatic suffering narratives. They faced challenges, certainly. They worked hard, absolutely. But they didn’t systematically destroy everything in their path to build something new. What did they do differently? They recognized that while difficulty is inherent to building companies, specific flavors of destruction are choices. The eighteen-hour days that destroy your health? That’s not dedication – it’s poor time management dressed up as commitment. The relationships that implode under pressure? That’s not inevitable – it’s the predictable result of unsustainable choices. Consider the actual research on productivity. Output doesn’t just plateau after fifty hours per week – it actively declines after sixty. Those heroic all-nighters don’t add value; they create problems that take longer to fix than the original task would have taken to complete properly. The founder coding until dawn isn’t moving faster – they’re creating technical debt with compound interest.

The normalized dysfunction serves specific interests, just not yours. Venture capital needs extreme outcomes to justify portfolio returns. The system pushes companies toward binary results: explosive growth or explosive failure. But what if your goal isn’t to be a lottery ticket in someone else’s portfolio? What if you’re trying to build something that lasts? Yes, some markets demand speed that seems to require unsustainable pace. Yes, some opportunities close quickly. Yes, some windows are brief. But even within those constraints, there are founders who capture markets without destroying themselves, who move fast without moving recklessly, who compete intensely without confusing intensity with self-destruction. The difference isn’t that they work less hard. It’s that they understand sustainability as a form of leverage. When you’re not constantly recovering from self-inflicted damage, you can maintain velocity longer. When you’re not perpetually exhausted, you make better decisions. When you preserve key relationships, you have support systems that multiply your capabilities rather than drain them. This isn’t about work-life balance in the conventional sense – startups don’t respect boundaries, and building something from nothing requires extraordinary effort. It’s about recognizing that sustainable extraordinary effort beats unsustainable heroics every time. Not in month one, perhaps, but certainly in year three, and absolutely in decade two.

ii. Complexity upfront
“Move fast and break things” became Silicon Valley’s motto, but there’s a problem: the things that break don’t always get fixed. They accumulate into a special kind of debt that compounds faster than financial obligations ever could. The conventional wisdom says don’t build anything until you absolutely need it. Ship the minimum viable product. Validate quickly. Iterate based on feedback. This sounds pragmatic, even wise. And for certain types of learning, it is. But there’s a crucial distinction between validating your market hypothesis and validating your architectural decisions. When do you actually need scalable architecture? Precisely when you’re scaling rapidly with no time to rebuild. When do you need proper security? Right after the breach that destroys customer trust. When do you need good documentation? The day your key engineer quits and nobody understands the system. The moments when you need robust foundations are exactly the moments when you can’t build them. I’ve watched this pattern repeatedly. A company achieves product-market fit with hastily built systems. Growth arrives. The systems that worked for hundreds of users start failing at thousands. But they can’t stop to rebuild – customers are depending on them; investors want growth; and competition, having caught on to their idea, is fierce. So they patch and work around and accumulate more debt, until eventually the entire system becomes so fragile that adding a simple feature takes weeks of careful navigation through historical accidents.

The alternative isn’t over-engineering or building elaborate systems for imaginary users. It’s recognizing the difference between essential complexity and accidental complexity. Essential complexity comes from the problem you’re solving – it’s irreducible. Accidental complexity comes from how you’ve chosen to solve it – it’s entirely optional. When you front-load essential complexity, you’re accepting what you’ll have to deal with eventually and handling it while you have time to think. When you defer it, you’re not avoiding it – you’re just ensuring you’ll have to deal with it under pressure, when mistakes are most costly. This applies beyond technology. Consider documentation. Writing clear documentation while building takes perhaps twenty percent longer initially. But trying to document a system six months later, when you’ve forgotten the reasoning and edge cases? That takes multiples of the original development time – if it happens at all. Or consider testing. Writing tests while developing features feels slower than shipping untested code. But the first production bug that takes down your system for hours, costing customer trust and engineering time? That erases any time saved by skipping tests. Plus, tests aren’t just about catching bugs – they’re about creating feedback loops that get tighter over time rather than looser. The key insight: you can choose when to pay complexity costs, but you can’t choose whether to pay them. Pay them early when you have resources and clarity, or pay them later with interest when you’re desperate. The math isn’t complicated, but it requires thinking beyond the current sprint.

iii. Patient capital
Startup culture has militarized time. Everything is urgent. Every deadline threatens existence. Every quarter demands hockey-stick growth. But this manufactured urgency doesn’t create success – it creates the kind of mistakes that compound into failure. I’m not talking about the investor version of patient capital – funds willing to wait longer for returns. I’m talking about something more fundamental: the patience to build correctly rather than just quickly. The capital of careful decisions that compound, not rushed choices that conflict. Consider two approaches to building any critical system. The “move fast” approach shortcuts everything possible to ship immediately. The patient approach takes time to model the problem properly, handle edge cases explicitly, build in observability. Takes three times as long initially. Six months later, the quick implementation is a maze of patches and workarounds. Every new feature requires navigating historical decisions nobody understands. The patient implementation? It’s handling real complexity cleanly because the abstractions were correct. New capabilities slot in naturally because the foundation was solid.

The difference isn’t just code quality – it’s velocity over time. The quick approach achieves instant speed by borrowing from future velocity. Every shortcut creates drag. The patient approach accepts lower initial speed to maintain sustainable velocity indefinitely. It’s the difference between a sprint that leaves you gasping and a pace you can maintain for years. Patient capital also means having the patience to say no. Not reflexively, but thoughtfully. Every startup faces the cursed progression: you solve one problem well, which attracts users, who request adjacent features, which you build, which dilutes focus, which degrades quality, which frustrates users. The patient approach defines what you are by defining what you aren’t. Those feature requests validate that you’ve solved the core problem, not mandates to solve every problem. But here’s the nuance: patience doesn’t mean slowness, and speed doesn’t mean recklessness. You can move quickly on decisions that are easily reversible and slowly on decisions that define your foundation. You can ship fast to learn about user behavior and build carefully when implementing core systems. The wisdom is knowing which is which. The psychology of impatience deserves examination. It’s not driven by market demands – markets actually reward consistency more than speed. It’s driven by anxiety. The anxiety that competitors will win. That investors will lose faith. That windows will close. But most windows stay open longer than we imagine, and the biggest risk isn’t missing opportunities – it’s destroying yourself trying to capture all of them.

iv. Building for success
Most founders make a fundamental architectural error: they build for the failure they can afford rather than the success they’re seeking. They create systems designed to handle current load, then act surprised when growth breaks everything. What does building for success actually mean? It means assuming your product will work and architecting accordingly. Not elaborate features for imaginary users, but infrastructure that won’t collapse when real users arrive. This isn’t optimism – it’s engineering. Take authentication as an example. The expedient path: basic sessions, passwords in the database, figure out the rest later. It works for hundreds of users. But success means thousands of users, then tens of thousands. Suddenly you need OAuth integration, enterprise SSO, audit logs for compliance. The migration becomes a nightmare because authentication touches everything. The success-ready approach: implement proper authentication from the start. Use battle-tested libraries. Include the patterns you’ll need at scale, even if you don’t fully implement them. This takes perhaps twice as long initially but saves months of dangerous migration at the worst possible time – when you’re actually growing.

Building for success means preserving optionality in architectural decisions. Choosing PostgreSQL not because you need its advanced features today, but because migrating databases after you discover you need them is organizational trauma. Using message queues not because your current load requires asynchronous processing, but because synchronous systems have scaling ceilings you’ll hit exactly when you can’t afford downtime. The mental shift is profound. Instead of asking “what’s the minimum we need now?” you ask “what decisions would we regret if we succeeded?” Instead of optimizing for the present, you optimize for the trajectory. You’re not building for who you are but for who you intend to become. I’ve seen teams take this to its logical conclusion. They ask: “If we woke up tomorrow with 10x our current users, what would break?” Then they fix those things preemptively. Not by building for 10x capacity – that would be wasteful. But by ensuring nothing would require fundamental restructuring. Their database can be sharded. Their API can be cached. Their authentication can handle enterprise customers. The counterintuitive result: building for success often takes less total time than building incrementally. Yes, each component takes longer initially. But you avoid the migrations, the rewrites, the emergency fixes that arrive when incremental approaches hit their limits. You’re not doing extra work – you’re doing the work once instead of repeatedly.

v. Autonomy
Every technical decision is actually a decision about power. Each shortcut you take, each dependency you accept, each corner you cut becomes leverage someone else will eventually hold over you. The path to sustainable building isn’t just about code quality – it’s about maintaining the autonomy to make decisions on your terms. When you build assuming continuous funding, you hand control to investors. When market conditions change – and they always do – you’re negotiating from weakness. When you choose proprietary platforms for convenience, you’re trading autonomy for velocity. What happens when they raise prices? Change terms? Get acquired? You’ve built your house on rented land. The alternative isn’t to refuse all dependencies – that’s impossible. It’s to be strategic about which dependencies you accept and how you structure them. Keep burn rates that could be sustained through revenue if needed. Build abstractions that allow provider switching. Document knowledge so it doesn’t live only in specific people’s heads.

A company I know maintained what seemed like paranoid independence. They used cloud services but through abstraction layers. They took investment but kept profitability as an option. They hired specialists but ensured knowledge transfer. When their cloud provider failed catastrophically, they migrated in hours while competitors were down for days. When venture funding dried up, they shifted to profitability while competitors folded. The autonomy principle challenges the “move fast and break things” ideology at its core. Moving fast by accepting dependencies isn’t actually moving fast – it’s borrowing speed you’ll have to pay back with interest. Breaking things isn’t innovation – it’s creating future obligations. Real velocity comes from maintaining the autonomy to make decisions based on what’s best for your product and customers, not what’s necessary to serve accumulated dependencies. This principle illuminates why front-loading complexity and patient capital matter. They’re not about perfectionism or over-engineering. They’re about maintaining the autonomy to build what you actually want to build, rather than what dependencies force you to build. Every proper implementation that seems to take longer actually preserves optionality. Every patient decision compounds into freedom.

vi. Reimagining velocity
The startup world has confused motion with progress, activity with achievement, speed with sustainability. Teams celebrate shipping features daily while their ability to ship anything meaningful gradually erodes. But real velocity – the kind that compounds rather than decays – requires thinking differently about movement. Burst velocity is sprinting – impressive briefly, exhausting quickly. Sustainable velocity is marathon pace – less dramatic but maintainable indefinitely. Most startups optimize for burst velocity, then wonder why they hit walls. The distinction shows up clearly in metrics. Burst-optimized teams measure features shipped per week. Sustainability-optimized teams measure capability accumulated per quarter. Can you deploy more frequently than last quarter? Can you onboard engineers faster? Can you handle more traffic without architecture changes? These measure your ability to maintain velocity rather than just current speed. I’ve seen teams implement what they call the 75/25 split. Seventy-five percent of time on customer-facing features, twenty-five percent on infrastructure and maintenance. That twenty-five percent isn’t overhead – it’s what prevents the other seventy-five percent from gradually declining to zero. It’s the difference between a garden that’s consistently tended and one that’s occasionally rehabilitated. The paradox: teams that optimize for sustainable velocity often achieve higher burst velocity when needed. Because their foundations are solid, they can occasionally sprint without breaking things. The capacity for burst emerges from sustainable practices, not despite them.

vii. Excellence and viability as foundation
The tech world has corrupted “minimum viable product” to mean “the least we can get away with.” But viable means capable of sustaining life. A truly viable product isn’t the minimum you can ship – it’s the minimum that can actually survive and grow. Think about biological viability. A viable organism isn’t stripped to the bare minimum – it has all essential systems functioning, even if simply. It might be small, basic, but it’s complete within its scope. That’s what viable actually means. Real MVP identifies the essential problem and solves it completely. Not solving every problem, but completely solving the essential one. Not adding every feature, but ensuring the core feature actually works. The minimum isn’t fewer features – it’s the minimum features implemented excellently. Excellence compounds in ways mediocrity never can. Excellent code attracts excellent contributors. Excellent documentation enables autonomous teams. Excellent user experience creates word-of-mouth growth. Each piece of excellence makes the next piece easier to achieve. The strategic value: excellence is hard to copy. Features can be cloned, pricing matched, marketing imitated. But excellence requires sustained commitment, cultural alignment, compound time. When you ship excellence from the start, time becomes your ally rather than your enemy.

viii. Pedagogical systems
The best systems are pedagogical – they teach people how to use them correctly. Well-designed APIs teach developers through structure. Good error messages explain what went wrong and how to fix it. Excellent documentation becomes unnecessary because the system itself provides guidance. When systems teach, knowledge scales without bottlenecks. New team members become productive quickly. Users solve their own problems. Support burden decreases as the product grows – the opposite of normal patterns. Building pedagogical systems requires thinking about future users, including future you. What will someone need to know to succeed? How can the system itself provide that knowledge? The investment in making systems self-explanatory pays compound returns through reduced support, faster development, higher satisfaction.

ix. Multiplication
Most companies scale through addition – more people, more features, more resources. But addition creates linear growth with sub-linear returns. The highest leverage comes from multiplication – making existing resources exponentially more effective. Before adding the tenth engineer, ask: could we make our nine engineers twice as effective? The math is compelling – doubling effectiveness is often easier than doubling headcount and avoids the overhead that comes with growth. This philosophical shift from scarcity to abundance changes everything. Instead of “we need more,” you think “we can do more with what we have by making what we have more capable.” It’s the difference between constantly seeking external solutions and developing internal capabilities.

x. Rethink the math
The standard startup math optimizes for specific outcomes that benefit specific people, usually not the ones building. We need different calculations that account for human sustainability, technical reality, and compound effects over time. Instead of “burn rate per month until funding,” calculate “sustainable capacity per person over years.” Instead of “features shipped per sprint,” measure “capability accumulated per quarter.” These aren’t just different metrics – they’re different philosophies about what matters. Consider technical debt’s real cost. Standard math treats it as acceptable overhead. Real math compounds it like credit card interest. Every shortcut taken today increases the cost of every feature tomorrow. A codebase with 20% technical debt doesn’t take 20% longer to develop – it takes exponentially longer as complexity interactions multiply. Here’s the calculation that matters most: what’s the minimum viable happiness? Not minimum viable product, but minimum viable happiness for the people building. What amount of growth, revenue, and impact makes the sacrifice worthwhile? What working conditions, relationships, and health are non-negotiable? Calculate backward from that, not forward from zero.

xi. Path
In forest management, controlled burns prevent catastrophic wildfires by deliberately burning accumulated fuel under manageable conditions. You choose when and how to burn rather than waiting for lightning to choose for you. Building companies works the same way. You can’t avoid all difficulty, all sacrifice, all risk. But you can choose when and how to face them. You can front-load complexity when you have resources to handle it. You can maintain sustainable pace instead of burning out. You can preserve autonomy instead of accumulating dependencies. This isn’t about avoiding ambition or settling for less. It’s about recognizing that sustainable achievement requires sustainable practices. That building something lasting requires lasting through building it. That success which destroys everything you valued isn’t success at all. Will this path work for everyone? No. Some problems genuinely require sprinting. Some opportunities really do close quickly. Some people thrive on intensity and wither without it. But for many – perhaps most – the unnecessary suffering we’ve normalized isn’t creating value; it’s destroying it.

The invitation is to build with the assumption you’ll succeed, and structure that building to survive success. Front-load the complexity you can handle thoughtfully. Maintain the autonomy to make decisions on your terms. Define velocity as sustainable capacity. Make excellence your minimum viable standard. Create systems that teach and multiply. And through it all, do different math. Calculate the full cost, not just the visible price. Measure what matters, not just what’s measurable. Optimize for the life you’re building, not just the company you’re creating. As the original essay postulated, there is no single brutal truth about building companies. But within that uncertainty, we still have agency. We can’t control whether we’ll be in the ninety percent that fail or the ten percent that succeed. But we can control whether we’re in the percentage that destroys themselves trying or the percentage that builds something sustainable regardless of outcome. That’s the controlled burn – not avoiding all fire, but choosing when and how to burn. Not eliminating all sacrifice, but being strategic about what you’re willing to sacrifice and what you insist on preserving. Not pretending the path is easier than it is, but refusing to make it harder than it needs to be. For those who need to build, this might be enough. For those who want to build and live, it might be essential. Either way, it’s a choice. And recognizing that it’s a choice – that’s the first step toward building differently.

Featured song:

Similar Post: Building Something New
Image Source