Basecamp just launched Fizzy, a Kanban tool that hit #1 on GitHub with 1,493 stars in under 24 hours. The marquee feature? Auto-delete. Cards that aren’t updated within 30 days disappear automatically—swept away to keep backlogs clean. Sounds helpful, right? It’s not. It’s gaslighting disguised as a feature.
Auto-Delete Makes Problems Disappear Without Solving Them
Gaslighting means making someone question their own reality. Auto-delete does exactly this to development teams. Your team knows problems exist—that critical bug, the stalled feature waiting on approvals, the technical debt you logged three weeks ago. Then you open Fizzy and see: “Backlog is clean! Only 10 active items!” Wait, where did that bug report go? Did we fix it? Did someone close it? No. It just disappeared because 30 days passed.
Problems didn’t get solved. They just vanished. Teams are left questioning what was real, what mattered, what they should have been tracking. That’s gaslighting. The tool creates a false sense of progress while actual dysfunction persists underneath.
As Danil Chernyshev points out in his critical analysis, auto-delete “discards the effort people made to log defects, steps to reproduce, and potentially important time-sensitive context.” Worse, it “symbolically sweeps those breadcrumbs under the rug, creating an anxious psychological environment.” Teams feel like they’re maintaining a clean backlog, but they’re really just watching their work disappear.
The Anxiety Loop: Forced Activity or Forced Amnesia
Auto-delete creates perverse incentives. Features stall for legitimate reasons—dependencies on other teams, waiting for legal approval, resource constraints, external blockers. In the corporate world, stalled pipelines are the norm, not the exception. Yet Fizzy’s countdown timer forces an impossible choice:
Option A: Add meaningless updates every 30 days just to keep the card alive. “Bumping for visibility.” “Still waiting on approval.” Busywork to trick the tool.
Option B: Let important work disappear into the void. Hope you remember to re-create it later. Accept the tool’s amnesia as your own.
Both options are dysfunctional. The first creates exactly the “long lists Fizzy was designed to eliminate”—except now they’re padded with fake activity instead of real progress. The second trains teams to ignore problems because the tool will make them go away eventually. Either way, you’re gaming the system instead of solving problems.
Chernyshev describes the feature as “anxiety-inducing with the countdowns.” That anxiety isn’t a bug—it’s the point. Fizzy uses stress to enforce its vision of what your backlog should look like, regardless of what your actual work requires.
What Good Tools Do: Linear’s Transparent Approach
Linear also prunes backlogs automatically. The difference? Transparency. Linear’s philosophy is blunt: “You don’t need to save every feature request or piece of feedback indefinitely. Important ones will resurface, low priority ones will never get fixed.”
However, here’s what Linear does differently: After 6 months of inactivity, items move to “Cancelled” status. Not deleted. Cancelled. They remain visible, queryable, and traceable. Teams can see what’s being deprioritized. They can review cancelled items. They can resurrect them if priorities change. The historical record exists.
Linear creates intentional friction against bad practices while maintaining transparency. As they put it: “The backlog way is based on what you thought then. The non-backlog way is based on what you think now.” Teams make deliberate decisions about what matters today, not six months ago. But those decisions are visible, not erased.
The contrast is stark. Linear exposes dysfunction honestly—if your Cancelled list is huge, you have a prioritization problem to solve. Fizzy hides dysfunction comfortably—if your backlog is clean, you must be doing great, right? One tool forces you to confront reality. The other lets you pretend problems don’t exist.
The Broader Pattern: “Helpful” Features That Hide Dysfunction
Fizzy’s auto-delete isn’t unique. It’s part of a pattern where “helpful” features make teams feel productive while systemic issues compound invisibly.
Jira’s infinite customization lets teams hide poor processes behind endless configuration. Can’t agree on a workflow? Just add more statuses! Estimates meaningless? Create a custom field! The tool becomes a monument to dysfunction instead of exposing it.
Similarly, Slack replaced documentation with ephemeral chat. Knowledge lives in search, theoretically findable but practically gone. “Did we decide on X?” becomes an archaeological dig through message threads instead of a reference to clear documentation. Convenience today, chaos tomorrow.
Research shows 30% of most teams’ work isn’t tracked in project management tools at all. Developers skip tickets for bug fixes and technical debt because the overhead isn’t worth it. Important business decisions get made from incomplete data, but the dashboard looks great.
Moreover, the pattern repeats: Tools make dysfunction comfortable instead of painful. They hide problems instead of exposing them. They create illusions of progress without demanding actual improvement. Short-term comfort leads to long-term crisis.
Why Fizzy’s Approach Appeals
Auto-delete is seductive. Clean backlogs feel good. Simplicity is attractive. “Out of sight, out of mind” reduces cognitive load. DHH’s philosophy resonates: “Products that start out with great promise and simplicity tend to accumulate cruft and complexity over time.”
Basecamp isn’t malicious. They’re solving a real problem. Backlog bloat is real. The endless accumulation of stale cards, forgotten features, and zombie bugs absolutely happens. Teams do need mechanisms to focus.
Nevertheless, you can’t automate your way to healthy processes. Simplicity should come from discipline, not deletion. Fizzy tries to enforce focus through automation, which creates a worse problem: invisible dysfunction. The backlog looks clean, but the underlying chaos remains—just hidden from view.
Good Tools Make Problems Visible, Not Invisible
Auto-delete isn’t a feature. It’s gaslighting. It makes problems disappear without solving them, creates anxiety to enforce arbitrary rules, and trains teams to ignore dysfunction because the tool will hide it automatically. That’s not helpful. That’s harmful.
Furthermore, good tools do the opposite. They expose dysfunction painfully and honestly. They make technical debt visible. They force teams to confront systemic problems. They create intentional friction against bad practices while maintaining transparency.
Fizzy chose comfort over honesty. Linear chose transparency over convenience. One lets you feel productive while problems compound. The other forces you to face reality and make deliberate choices.
If your project management tool makes problems disappear automatically, it’s not helping your team improve—it’s helping you lie to yourselves. Backlog bloat is a symptom, not the disease. Deleting the symptoms doesn’t cure anything. It just makes the disease invisible until it’s too late to treat.
