Some of the best software ever made stopped updating years ago.
Indie devs talk about shipping. Nobody talks about stopping.
WinZip is still on millions of computers even though Windows handles zip files natively now. People download it on instinct. It found a narrow problem, solved it well, and earned a place in muscle memory that’s lasted decades.
VLC plays every video you throw at it. The current version doesn’t look much different from the version I had on my college laptop. Nobody is asking VLC for an AI subtitle assistant. It plays videos. That’s the whole job.
The calculator on your phone hasn’t changed in any meaningful way since 2010. f.lux predates Night Shift and still has loyal users who prefer it. Notepad. Paint. Software that solved a narrow problem so well that adding to it would make it worse.
I’ve been thinking about this category a lot lately, because I accidentally joined it.
A few weeks ago, I sat down to plan the next update on my app and realized I didn’t have one.
No new features in the backlog. No bug reports waiting. The reviews kept landing at five stars. Subscribers kept showing up, slowly, on their own. The thing was just running.
That feeling caught me off guard. As a PM, I’ve spent fifteen years assuming the work is never done. Roadmaps stretch out forever. There’s always another quarter, another feature, another thing to add. The idea that a piece of software could just be finished felt almost inappropriate.
But it’s possible. It’s actually how some of the best software in our lives works.
This is possible inside companies, too, especially with internal tools. You can flip an app into bug-fix-only mode and let it run. It works.
But most companies don’t do this. They keep adding. And I think two failure modes explain why.
The first failure mode is weak product direction.
Without someone fighting for the next growth area, teams keep enhancing apps that don’t need enhancing. The roadmap fills with motion that doesn’t move anything. Ship something. Anything. Justify the team.
You can spot this when a feature ships and nobody can name the metric it moved. The release notes get longer. The product gets heavier. The user experience gets a little worse. And six months later, you’ve added forty new things, and nothing actually changed.
The second failure mode is sunk cost meeting risk aversion.
The team knows the app is mostly done. They can feel it. But upgrading it carries real risk. New features can break what works. Touching old code is dangerous. So instead of doing the harder thing, which is accepting that the app’s job is finished and building a roadmap to replace it, they pour money and time into marginal improvements.
This is the worst of both worlds. The app keeps consuming resources. The new thing never gets built. And the team can’t honestly answer the question every leader should be asking: why are we still working on this?
I want to be careful here. Many of you reading this aren’t working on solo projects. You’re inside companies whose products absolutely need to keep moving. Slack can’t stop. Salesforce can’t stop. Your fintech app, your ecommerce platform, your B2B SaaS tool, none of those are WinZip.
The argument isn’t stopping. It’s time to be honest about which parts of your product are still earning their roadmap slots and which are just consuming them.
Most products aren’t done. But most teams act like done isn’t an option. So they keep adding even when the smarter play is to pause, replace, or kill.
The team that ships eight features in a quarter and can’t tell you what changed isn’t shipping. They’re in motion. There’s a difference.
If you want to run a version of this on your own work, here’s a five-step audit:
List every feature your team shipped in the last two quarters. Not the projects, the actual features that landed in production.
For each one, name the metric it moved. Not the metric it was supposed to move. The one that actually moved.
Mark every feature with no answer. Those features aren’t features. They’re maintenance dressed up as progress, or they’re bets that didn’t pay off and never got declared done.
Ask whether those features earned their cost. Engineering time, design time, PM time, the opportunity cost of everything you didn’t build instead. If the answer is no, that’s data.
Decide what the honest answer means. A roadmap full of unmoved metrics is either a roadmap problem or a leadership problem. Both are fixable. Pretending it’s fine is not.
Final Thoughts
My app might break tomorrow. Apple might change something on its end. A subscriber might find an edge case I missed. If that happens, I’ll fix it.
But until then, it’s done. And I’m trying to let it be done without inventing a roadmap to justify keeping the project alive in my head.
The harder version of this question is the one I keep landing on: what would happen if you applied the same honesty to the work you’re doing right now? Not the indie side project. The real one. The thing you’re paid to ship.
Some of it is moving the business forward. Some of it is just motion. The job is to know the difference, and to have the courage to say so out loud.
Mike Watson @ Product Party
P.S. Want to connect? Send me a message on LinkedIn, Bluesky, Threads, or Instagram.