Should you define kill criteria before launching?

From the SoleOS answers series — written about our own product space; grounded in published definitions and documented behavior, never invented numbers.

Yes, define kill criteria before you launch — not because you're expecting failure, but because the version of you that hasn't spent six months and emotional capital on the project is the only version capable of setting an honest bar. Kill criteria written after launch get rationalized away one "just two more months" at a time. Kill criteria written before launch are just facts you agreed to earlier, which is a much harder thing to argue with.

This matters more for solo founders running several products than almost anyone else. You don't have a board forcing quarterly reviews, and you don't have a boss asking why an app that hasn't grown in eight months is still getting your Tuesday afternoons. You're both the founder who wants to believe and the operator who has to be honest. Kill criteria are how you outsource that argument to your past self.

Why "I'll know it when I see it" doesn't work

Sunk cost isn't a bias you're immune to because you've read about it. It's structural: the more time and identity you've invested in a project, the more your brain will find reasons the next data point doesn't count. A flat month is "seasonality." A missing signup spike is "the tracking's probably off." A refund wave is "just a bad cohort." Every one of those explanations might be true individually — that's what makes them so effective at delaying a decision indefinitely.

Kill criteria fix this by moving the judgment call to a moment when you have no stake in the outcome yet. Before launch, you don't know if this app will be the one that works. You can write "if it's not at $500 MRR by month 6, I sunset it" without any emotional cost, because month 6 hasn't happened. That's the whole trick.

What good kill criteria actually look like

Vague criteria don't survive contact with hope. "If it's not doing well" is not a criterion — it's a mood. Useful kill criteria have three properties:

A number, not a feeling. MRR, paying customers, D30 retention, organic signups per week — pick a metric you can already measure or will be able to measure from day one. If you're not sure what a healthy version of that number even looks like yet, that uncertainty is fine; write down your best guess and revise it once, at a fixed date, not continuously.

A date, not "eventually." "If it hasn't grown" needs a deadline attached, or it never triggers. Six months is a reasonable default for a side project — long enough to get past launch noise, short enough that you haven't built your identity around it yet.

A pre-committed action. Not just "reconsider" — decide now what happens. Sunset it, stop paying for ads, stop building new features and let it run on autopilot, or fold it into another product. The action matters more than the trigger, because "reconsider" is where most kill criteria go to die.

A workable example: "By day 180, if MRR is under $300 and there's no upward trend over the trailing 30 days, I stop active development and either sunset or leave it running as-is with zero further time investment." That's specific enough that future-you can't argue with it, and generous enough that it's not a hair-trigger.

Kill criteria vs. pivot criteria

Not every miss should end in a shutdown. Some criteria should trigger a pivot instead of a kill — a change in pricing, audience, or positioning before you give up on the underlying idea. The distinction matters because conflating them is how projects drift for years in a kind of undead state: not growing, not killed, not really being worked on either.

A reasonable structure is two thresholds. A softer one at month 3 or 4 that triggers a specific pivot experiment (new price point, new landing page, new channel), and a harder one at month 6 or 9 that triggers the actual kill decision if the pivot didn't move the number. This gives the project one real second chance without turning "one more thing to try" into a permanent status.

Where kill criteria fit in a running review cadence

Kill criteria only work if you're actually looking at the number on the date you promised. If you're not checking metrics on a fixed cadence across your apps, the deadline just slides — you don't remember to look until month 9, and by then you've already built a new feature you don't want to have wasted. It's worth pairing kill criteria with a consistent review habit, which is its own decision worth making deliberately rather than winging.

This is also where the practical mechanics matter: if your revenue lives in Stripe for web and RevenueCat for mobile, and your traffic lives in GA4 and Search Console, checking a kill-criteria date means opening four dashboards and reconciling numbers that often don't match on their own — see tracking Stripe and RevenueCat together for why that mismatch is normal, not a red flag. A portfolio dashboard like SoleOS pulls those into one view so the "did we hit the number" check takes two minutes instead of an afternoon of tab-switching — worth disclosing since this is SoleOS's own blog writing about its own space. If you're running one project and you're comfortable eyeballing two dashboards on a set date, you don't need that; a calendar reminder and a spreadsheet will get the same job done. See SoleOS vs a spreadsheet for an honest comparison of where each holds up.

Kill criteria across a portfolio, not just one app

If you run more than one product, kill criteria also protect your best project from your worst one. Time and attention are the scarce resource, not ideas — every week spent nursing an app that already missed its own deadline is a week not spent on the one that's actually growing. Writing kill criteria per-app, and reviewing them together rather than in isolation, forces the comparison you'd otherwise avoid. Real numbers from a 10-app portfolio go into what that comparison tends to look like in practice — it's rarely as even as people assume going in.

Frequently asked questions

What if I don't have enough data to set a realistic number?

You won't, and that's fine — the first number you write down is a placeholder, not a prophecy. Set it anyway, launch, and revise it once at a fixed early checkpoint (30 or 60 days) based on what you actually observe about signup rate and early conversion. After that one revision, stop touching it; continuous revision is just sunk-cost reasoning wearing a spreadsheet.

Isn't this overly pessimistic for a side project I'm excited about?

Kill criteria aren't a prediction that the project will fail — they're insurance against the specific failure mode of running something on autopilot for two years because you never made an explicit decision to stop. Excited founders benefit from them just as much, because the criteria only trigger if the number is actually missed; if you're growing, they never come up.

Should kill criteria be different for a paid app vs. a free one with ads or a waitlist?

Yes — the metric should match the actual business model. A subscription app should probably use MRR or paying customers; a free app monetizing later should use retained weekly actives or waitlist signups per week, since revenue won't exist yet to measure. Check the metrics dictionary if you're unsure which formula matches what you're trying to track.

What's the difference between a kill criterion and just checking in on vibes every few months?

A kill criterion is decided in advance and specifies both a number and an action; a vibe check happens after the fact and lets you talk yourself into whatever conclusion feels best that day. The first one binds future-you; the second one is just future-you negotiating with himself, which he usually wins by doing nothing.

Do kill criteria apply to apps that are profitable but stagnant, not losing money?

Yes, and this case gets missed most often. A project that's flat but not actively losing money doesn't feel urgent to kill, so it quietly absorbs maintenance time indefinitely. If you set a growth-based criterion, not just a revenue-floor one, you catch this — "if MRR hasn't grown in 6 months despite active work" is a legitimate kill trigger even at $2k MRR.