Heavy Boats: The Hidden Cost of Complexity
High tides float all boats. But when the tide goes out, the heavy boats find themselves on land.
When we build a business—particularly a software business—we tend to make fast decisions and add features with little regard to cost and complexity. During growth phases, this feels rational. Revenue is climbing. Headcount is expanding. The market rewards speed over efficiency.
Then the tide goes out.
The Weight We Accumulate
Every feature we add carries ongoing costs that extend far beyond the initial development sprint:
- Maintenance burden: Bug fixes, security patches, compatibility updates
- Cognitive load: Engineers must understand the feature to work around it, even if they never touch it
- Testing surface: Every new code path multiplies the combinations that need validation
- Support overhead: Documentation, training, customer tickets
- Infrastructure costs: Compute, storage, monitoring, logging
These costs compound. A feature that took two weeks to build might consume two engineer-months per year in perpetuity. Multiply that across dozens of hastily-added features, and you’ve built a heavy boat.
Why We Do It Anyway
The pressure to accumulate weight is structural, not just behavioral.
Sales-driven roadmaps: A prospect wants Feature X to close the deal. We build it. That prospect represents one contract; the feature becomes everyone’s problem forever.
Competitive anxiety: A competitor announces something. We rush to match it without validating whether our customers actually want it.
Sunk cost reasoning: We’ve invested in a feature, so we resist deprecating it even when usage data shows almost no one uses it.
Founder optimism: In the early days, everything feels temporary. “We’ll clean this up later.” Later never comes, and the temporary becomes permanent.
Growth-stage abundance: When capital is cheap and revenue is growing, inefficiency hides in the margins. We hire around problems rather than solving them.
The Tide Goes Out
Economic contractions. Market corrections. Funding droughts. Churn spikes. Eventually, every company faces a period where the easy growth stops and the underlying economics get examined.
This is when heavy boats run aground.
Companies with bloated feature sets discover they can’t cut costs without cutting capabilities their remaining customers depend on. The codebase has become so intertwined that removing anything risks breaking everything. The team that built the features has turned over, and the institutional knowledge is gone. The technical debt that was ignorable at 40% year-over-year growth becomes existential at -5%.
Meanwhile, the lighter boats—the ones that maintained discipline during the good times—find themselves with options. They can cut deeper if needed because there’s less entanglement. They can pivot faster because there’s less to move. They can acquire distressed competitors because they have the operational capacity to absorb them.
Building a Lighter Boat
Discipline during abundance is difficult but not complicated.
Feature budgets: Treat features like financial capital. Every addition requires justification, and there’s a cap. Want to add something? Identify what you’re removing to make room.
Deprecation as a practice: Schedule regular reviews specifically to identify candidates for removal. Make sunsetting a celebrated activity, not a failure.
True cost accounting: Before greenlighting a feature, estimate the five-year total cost of ownership—not just build cost. Include maintenance, support, infrastructure, and opportunity cost of engineering attention.
Usage-based pruning: Instrument everything. If a feature has <5% adoption after reasonable time, it’s a deprecation candidate regardless of who asked for it or how much it cost to build.
Saying no: The most powerful feature is the one you don’t build. Every “no” preserves capacity for the features that actually matter.
The Paradox of Constraints
There’s an uncomfortable truth here: constraints produce better outcomes than abundance.
Teams with unlimited resources tend to solve problems by adding—more features, more people, more infrastructure. Teams with constrained resources must solve problems by improving—better architecture, cleaner code, smarter prioritization.
The companies that thrive through downturns often aren’t the ones that simply survive them. They’re the ones that built the operational discipline during the good times that makes them resilient when conditions change.
The tide will go out. It always does.
The only question is whether you’ve been building a boat that can handle it.
Build light. Stay light.
© 2026 Chris Bollerud, Bollosoft. Unauthorized reproduction prohibited.