Shipping a feature feels like progress. Removing one feels like failure, or at minimum, like picking a fight. You have to convince people that less is genuinely better, not just a polite spin on a budget cut or a missed deadline. You have to tell users who rely on the thing that their workflow doesn’t matter enough. And you have to do all of this while your organization’s instinct is screaming that software should accumulate, not shrink.
Basecamp has deleted more features, more deliberately, than almost any software company of its size. It’s worth examining how, and why that habit built a more coherent product than the alternative would have.
The Setup
Basecamp launched in 2004 as a project management tool for web design agencies. It was simple to the point of being sparse: messages, to-dos, files, milestones. No Gantt charts. No resource allocation views. No dependency tracking. Competitors had those things. Basecamp didn’t, and that was a deliberate choice.
But over the years, features accumulated anyway. Some were added in response to loud customer requests. Others were ideas the team genuinely believed in. By the time Basecamp 3 shipped in 2015, the product had grown in ways that weren’t entirely coherent. There were multiple overlapping ways to communicate inside a project. The question of where something “lived” inside Basecamp had become genuinely confusing.
Then, in 2019, the company did something unusual. They announced Basecamp Personal, a free tier, and restructured the product significantly. But more tellingly, when they released HEY (their email product) in 2020 and then worked toward Basecamp’s next iteration, they made a series of cuts that were painful enough to document publicly.
What Happened
The most instructive episode wasn’t a single dramatic deletion. It was a philosophy that hardened over time into an explicit company stance.
In their book “Shape Up,” Basecamp co-founder Ryan Singer describes a concept they call the “circuit breaker.” If a feature isn’t shippable within its appetite (a fixed time budget, not an estimate), the work gets cut, not extended. The default is to remove scope, not add time. This sounds obvious as a scheduling principle. As a product principle, it’s radical: you are pre-committing to the possibility that a partially-built feature simply won’t ship, and that this is acceptable.
This framework forces a question most product teams avoid: is the half-finished version of this feature worth keeping at all? Usually, the honest answer is no. A feature that exists but works poorly is worse than no feature. It creates support load, documentation burden, and user confusion. It occupies space in the interface and in the mental model of everyone who opens the product.
Basecamp co-founder David Heinemeier Hansson has written about the “interest” that features accrue. Every feature you add requires future consideration every time you touch the codebase. Every UI element has to be maintained, tested, documented, and explained. Software debt is real, but feature debt is underappreciated. It doesn’t show up in a profiler. It shows up in slowed decisions, confused users, and engineers who are afraid to refactor because they don’t know what might break.
The deletion that illustrated this most clearly was when Basecamp removed their built-in chat feature during one of their product resets. Chat had been added because customers asked for it. But it created a split between where conversations happened: were you talking in messages, in comments on a to-do, or in chat? The answer was “all three, inconsistently.” Removing the feature meant telling some users their workflow would break. Basecamp did it anyway, and pointed those users toward dedicated tools like Slack that do chat better than a project management tool reasonably can.
Why It Matters
Most product teams can’t do this. Not because they lack the technical ability, but because the organizational structure makes it nearly impossible.
Consider the incentives. The PM who championed the feature is still at the company. Removing it is a public admission that the original decision was wrong. Engineering teams take pride in what they build. Customer success has promised that the feature will improve. Sales has used it in pitches. The feature has a constituency, and that constituency didn’t disappear just because the feature turned out to be a mistake.
This is why the companies that delete features successfully tend to share a structural trait: the people with the authority to remove things are the same people who built the product from scratch and have a clear picture of what it’s supposed to be. At Basecamp, Heinemeier Hansson and Jason Fried have both the technical context and the organizational authority to make the call. There’s no committee that has to approve the deletion. There’s no stakeholder whose feelings have to be managed before the PR goes out.
At a larger company, removing a feature requires justifying the decision to people who weren’t involved in building it, who don’t fully understand its dependencies, and who have legitimate concerns about the users who depend on it. This isn’t bureaucracy for its own sake. Those concerns are often valid. But the process adds enough friction that most feature deletions die in a meeting before they reach a keyboard.
There’s also a technical dimension that gets underestimated. Deleting a feature in a codebase that’s been in production for years means understanding every place it touches. Database columns that exist because of that feature. API responses that include its data. Mobile app versions still in the field that expect it to exist. The actual code deletion is sometimes the smallest part of the job. Testing that nothing broke in the removal is harder than testing that something works in the addition. You’re proving a negative.
What We Can Learn
The Basecamp case suggests a few things worth taking seriously.
First, features need owners who can kill them. If no one has both the authority and the incentive to remove something, it will accumulate indefinitely. This is related to the broader argument that the engineer who writes less code is often worth more: the value is in judgment, not output.
Second, the right time to plan a deletion is at the moment of creation. Basecamp’s “appetite” model forces this. If a feature isn’t fully shippable within a set time, the answer is to scope it down until it is, or to kill it. Teams that build with a sunset criterion baked in (“we’ll revisit this in six months and cut it if adoption is below X”) have a much easier time removing things, because the removal was always part of the contract.
Third, user complaints about removal are not the same as user need. When Basecamp removed features, some users were loud about it. But the loudest users are rarely representative of the median user. The median user may not even know the feature existed. Product teams that optimize for the most vocal subset of their users will never remove anything, because there’s always someone who uses every feature, and that person will always write an angry email.
The hardest part isn’t the technical work. It isn’t even the user communication. It’s the internal agreement that the product is better as a smaller, more coherent thing. Most organizations never reach that agreement, which is why most software keeps growing until it collapses under its own weight, or gets rebuilt from scratch by a competitor who starts with fewer constraints.
Basecamp built the habit of subtraction. That’s rarer than it sounds, and harder to maintain than it looks from the outside.
