Benchpad blog
Why software cannot get simpler (and what it costs you)
Complexity in software is a one-way ratchet. Here's the economics, the incentives, and why the tools you depend on will always drift toward bloat — and what to do about it.
In 2004, Basecamp launched with a handful of features. To-do lists. Messages. A shared file space. You could learn the whole product in an afternoon.
By 2020, Basecamp had added: check-ins, HEY Mail, Campfire chat, pings, automated check-ins, card tables, hill charts, a Docs section, email forwarding, and a client portal. None of these were in the original product. All of them had been added in response to genuine user requests.
This is not a story about Basecamp being bad at product. Basecamp is run by people who have written more about product simplicity than almost anyone. It's a story about a force that acts on all software, regardless of the intentions of its makers.
Complexity in software is a ratchet. It turns in one direction.
The feature request problem
Feature requests don't arrive equally distributed. They arrive biased.
Users who want a feature that doesn't exist will email, tweet, upvote the forum post, and complain. They are highly visible and highly motivated. Their frustration is real and often justified.
Users who benefit from the product's current simplicity typically don't email to say so. They don't write forum posts defending the absence of a feature they don't want. Their satisfaction is invisible.
This is a structural information asymmetry. The product team's signal — the requests they receive, the churn reasons they collect, the support tickets they respond to — is dominated by demand for features that don't exist. There is no corresponding signal for features that should never exist.
The result: every rational product team, receiving these signals, adds features over time. This is not laziness or weak product thinking. It is the correct response to the information they have. The problem is that the information is systematically incomplete.
Barry Schwartz wrote about this in The Paradox of Choice (2004): adding options to a product increases its appeal to potential buyers while simultaneously increasing the cognitive burden on current users. The new feature satisfies the vocal minority who wanted it, attracts new users who value it, and imposes a small overhead cost on every existing user who now has to navigate around it.
Each individual addition is defensible. The cumulative effect is a product that becomes harder to use with every improvement.
Hotelling's law and the convergence trap
In 1929, the economist Harold Hotelling described a phenomenon now known as Hotelling's law: competitors in a market tend to converge on similarity rather than differentiate.
His original example was two ice cream vendors on a beach. If they start at opposite ends and can freely move, each vendor has an incentive to move toward the center — capturing the customers between them and the other vendor while keeping their side of the beach. Eventually, both vendors end up in the middle, side by side.
The law applies to software feature sets. When Notion added databases, Coda added databases. When Notion added wikis, Confluence added a consumer product. When Obsidian added plugins, other markdown editors added plugins. Competitors watch each other and migrate toward the same feature set, because any gap is a potential attack vector.
This creates a product landscape where all major players in a category converge toward the same complex, maximalist feature set — even when most users of each product don't need or want most of those features.
The vendors are all selling the same ice cream from the same part of the beach.
The counter-move — genuine differentiation through deliberate constraint — is available but rare, because it requires resisting the rational response to competitive pressure. You have to choose not to build something a competitor has, while knowing that their users will cite it as a reason to switch to them and your users will cite it as a reason to switch away.
The maintenance burden nobody accounts for
In software engineering, there is a concept called technical debt — the accumulated cost of shortcuts and quick fixes that eventually have to be reworked. It's well-understood that adding features without refactoring creates technical debt.
Less discussed is what might be called cognitive debt — the accumulated burden on users of each feature added to a product.
Every feature in a product is something a user must:
- Learn the existence of (feature discovery)
- Decide whether to use (feature evaluation)
- Learn how to use if they decide yes (feature education)
- Maintain their understanding of as it changes (ongoing cognitive maintenance)
- Navigate around if they decide no (feature avoidance)
Items 1, 2, and 5 happen automatically, whether or not the user ever uses the feature. The cognitive debt from unused features is not zero. It's the permanent overhead of knowing something exists and having decided not to use it.
A product with 200 features has a higher cognitive overhead than a product with 20 features, even if you use the same ten features in both. The 180 unused features in the complex product are each, individually, a tiny tax. Together, they constitute friction.
This is the structural problem with "we'll add it but you don't have to use it." In theory, optional features have no cost to non-users. In practice, the cost is diffuse but real: in the visual noise of menus with 30 items, in the search results cluttered with settings you've never touched, in the documentation that has to explain everything, in the mental model that grows more complex to accommodate each new thing.
Why simplicity can't be restored from within
The counterintuitive conclusion from all of this: once a product acquires complexity, it cannot simplify itself without catastrophic damage.
The reasons are structural:
Every feature has users. A feature used by 3% of users is, at a million users, a feature used by 30,000 people. Removing it generates 30,000 complaints, 30,000 churns, and a PR disaster — even if it would improve the experience for the other 970,000. The 970,000 won't write blog posts about the feature that was removed. The 30,000 will.
Complexity creates dependencies. Users build workflows around features. Remove a feature and you break a workflow. The user doesn't just lose the feature — they lose the hours they spent integrating it. This makes removal effectively permanent for any feature that's been live long enough to acquire users.
The product has been sold on its feature set. Sales decks, landing pages, and comparison tables market a product by its features. Removing features creates a mismatch between what was promised and what's delivered. Enterprise customers have contracts specifying features that must remain available.
The team has been hired around it. The people who built the feature have stakes in it: their performance reviews, their portfolio, their colleagues who depend on it. Internal removal requires organizational will that is difficult to sustain against diffuse resistance.
Evernote tried to simplify in 2019 under new leadership. They reduced team size and feature scope. Users revolted. Coverage was brutal. They reversed course.
The ratchet turns one way.
The case for starting simple
This is why the starting conditions of a product matter more than its iteration roadmap.
A product that starts with three features and adds deliberately is not the same as a product that starts with thirty features and tries to simplify. The starting point sets the frame — for users' expectations, for the team's habits, for the codebase's architecture.
A user who finds Benchpad and learns that it has three pads has already signed the implicit contract: this is a simple tool. When they hit the constraint — "I wish I had a fourth pad" — the constraint is legible. It was clearly chosen. They can evaluate whether the tradeoff is worth it to them.
A user who finds Notion and learns it can do everything has signed a different contract: this tool can do whatever I need it to do. When they hit a limitation — "I need my notes to work offline" — it feels like a failure. They were promised everything. They didn't get it.
The complexity ratchet is partly a story about promise management. Simple products make small promises. Complex products make large ones. Small promises are easier to keep; large ones accumulate debt with every unmet expectation.
What this means for the tools you choose
The trajectory of a tool matters as much as its current state.
A note app that is currently simple but has venture funding, a growth team, and a roadmap full of features is a note app that will be significantly more complex in two years. The ratchet is already engaged. The structure — the competitive pressure, the feature request bias, the Hotelling's law convergence — will do its work.
A note app that is currently simple, charges a sustainable price per user, has no growth team, and is run by people who've published writing about why they refuse to add features — that's a different trajectory.
You're not choosing a product. You're choosing a point on a curve, and the direction the curve is heading.
Benchpad is three scratchpads. Offline-first. Plain markdown. $10/year. Start writing free →
Benchpad Interface
Get Benchpad
On every platform
Native apps for iPhone & Android, and a Mac menu bar & Windows tray app — same three pads, offline-first, synced everywhere.
Benchpad
Try it free.
No credit card required.