Killing Your Darling: When to Shut Down a Failing App

Every solo builder has at least one app they keep meaning to revisit. It sits in their developer account, pulling a small monthly fee, getting the occasional one-star review, and quietly draining attention from things that could actually grow. The question is never really "is this app struggling?" Most founders already know the answer. The question is: how bad does it have to get before you actually shut it down?

Without a clear threshold, you default to hope. Hope is expensive.

This post is about replacing hope with criteria. Specific, pre-agreed criteria that tell you when an app has earned a graceful exit, so you are not making that call at 2am on emotion alone.

Why Founders Wait Too Long

The psychology here is well-documented outside the app world. Sunk cost. Identity attachment. The belief that one more update might change the trajectory. None of those are unique to software.

But apps have a particular trap: they can look alive while being commercially dead. Downloads trickle in from old ASO. A handful of users open it monthly. Revenue covers the Apple developer fee with a little left over. Everything feels like it is on the verge of turning a corner.

Meanwhile, you are not building the next thing. You are maintaining the last thing.

The longer you wait, the harder the decision gets, because now you have two more months of sunk cost. Pre-committing to kill criteria is the only reliable way out of this loop.

Build Your Kill Criteria Before You Launch

The right time to define failure is before you ship, not after. When the app is still hypothetical, you can be clear-eyed about what "not working" looks like. Once it is live, every number gets interpreted generously.

Here is a practical framework. Pick thresholds that fit your context, but the categories are non-negotiable.

1. A Hard Deadline

Set a review date at the start. Twelve weeks post-launch is a reasonable minimum for most consumer apps. At that date, you evaluate. You do not extend the deadline without a specific reason tied to a specific change you made.

If you already launched without a deadline, set one now. Pick a date 60 days out and commit to it in writing.

2. A Revenue Floor

Decide what revenue the app needs to be generating by your review date to justify ongoing investment. This is not a "nice to have" number. It is a floor. Below the floor, the app is dead unless something structural changes.

For most indie hackers, that floor should at minimum cover the cost of your time at some rate you consider acceptable. If you are spending four hours a month on support and updates, and the app earns less than you would charge for four hours of consulting, you are subsidizing someone else's cheap software.

3. A Retention Signal

Downloads are noise. What matters is whether people keep using the app after day one.

Define a specific retention metric before launch. Day-7 retention is a common starting point for consumer apps. If fewer than a fixed percentage of users return after a week, the app has not solved a problem they care about returning to solve. A single-digit rate, for most non-utility apps, is a warning sign worth taking seriously.

4. A Growth Signal

An app does not need to be growing fast. But it should be growing. Flat or declining monthly active users for more than two consecutive review periods, absent a deliberate strategy change, is a signal the market has made its decision.

If paid acquisition is out of scope for your budget, organic growth signals like store search ranking trends and referral rate matter more. A shrinking organic footprint with no corresponding change in the product is hard to reverse without significant effort.

Applying the Criteria After Launch

You have set your thresholds. Your review date arrives. Here is how to work through the data without letting bias creep in.

Pull the Numbers First, Then Look

Before you look at any metrics, write down your answer to this question: "What do I expect to see?" Then open the dashboard. The gap between expectation and reality is where honest evaluation lives.

If you expected 500 downloads and got 500, but you expected 20% day-7 retention and got 6%, that is a product problem. The app is getting discovered. People are trying it and not coming back. That is a specific signal, not a vague failure.

If you expected 500 downloads and got 80, but retention is 30%, that is a distribution problem, not a product problem. Those two situations have very different next steps.

The Three Outcomes

After applying your kill criteria, one of three things is true.

The app clears all criteria. Keep going. Set new thresholds for the next review period. Raise the bar.

The app fails one criterion but passes the others. This is not automatically a death sentence. But it requires a specific, bounded intervention. If retention is below threshold, you have one review cycle to test a fix. If you cannot move retention with a focused effort, the underlying value proposition is probably wrong.

The app fails two or more criteria. Shut it down. The data has spoken. Every week you spend nursing it back is a week not spent on something with a cleaner signal.

The "Zombie App" Case

There is a fourth scenario that looks like the first outcome but is not. The app clears your revenue floor, but only because of legacy users. New user growth is flat or negative. Early retention has declined over the past few periods. You have not shipped anything meaningful in months.

This is a zombie app. It is alive on paper and dead in practice. The correct call is still a shutdown, or a deliberate, resourced re-launch treated as a new product. Slow maintenance without growth investment is just paying to keep the corpse warm.

How to Actually Shut It Down

Shutting down cleanly matters. You have users, even if not many. They deserve a heads-up.

Give users at least 30 days notice. A simple in-app message and an email to anyone who signed up works. Explain what is happening plainly: the app is being discontinued on a specific date. If there is any way to export their data, make it easy.

Removing the app from the stores stops new downloads but does not break the experience for existing users immediately. On iOS, the app keeps working on devices that already have it installed until Apple's systems eventually de-list it. Plan your server-side shutdown separately from the store removal.

Cancel subscriptions, process any refunds you owe, and document what you shut down and when. That last step is not bureaucracy. It is useful data for the next time you make a portfolio decision.

What You Learn From Killing Something

Every shutdown teaches you something a success cannot. A dead app tells you which of your assumptions about user behavior were wrong, which distribution channels did not work for this category, and which problems you thought people had urgently they actually had tolerably.

That information is directly applicable to the next thing you build. Founders who run experiments and shut them down cleanly tend to build better second and third products, because they are working from evidence rather than intuition.

Goodspeed's discovery layer is built around this idea. Before a line of code is generated, market signal gets scored across multiple sources so you know, before you build, whether the idea has real demand behind it. That does not eliminate the need for kill criteria. But it shifts the odds at the start and changes what failure looks like when it arrives.

Pre-Commit, Then Act

The conclusion is simple. Define your kill criteria before you launch. Put them somewhere you will see them at your review date. When the date comes, apply them mechanically, not emotionally.

If the app clears, great. Keep building. If it does not, shut it down cleanly and take the lessons with you. The goal is not to keep apps alive. The goal is to ship things that work.

Your next idea deserves the attention you are currently giving to something the market already voted on.