Paul
One of the strange consequences of being able to ship platforms in a week with Claude Code is that you also have to develop a much faster sense of when a platform isn't working, because the old model where you spent months building something and felt obligated to give it a year before declaring it dead doesn't really apply anymore. When the build cost was high, the sunk cost made sense as a reason to keep going. When the build cost is low, the sunk cost is a trap that keeps you working on things that should have been put down weeks ago, and the founders who don't develop a clear sense of when to stop end up with portfolios full of zombie platforms that drain attention without producing anything.
I want to write about this honestly because I'm in the middle of figuring it out myself, where I've shipped more than ten platforms in the past few months and some of them are working and growing while the others only receive a few visitors daily, and the question of which ones deserve more time versus which ones I should let go is genuinely one of the harder problems I'm trying to solve right now. The conventional advice on this topic tends to be either "never give up" or "fail fast," both of which miss the actual nuance for solo founders running portfolios, and I think there's a more useful conversation to be had about what the actual signals are.
Why this is harder than it sounds
The first thing to acknowledge is that knowing when a platform isn't working is genuinely difficult, and not because founders are dumb but because the signals are noisy in ways that make it easy to convince yourself either direction. A platform with low traffic might be a failure or it might be early in its SEO ramp where the trajectory is positive even though the absolute numbers are small. A platform with some users but no revenue might be the seed of something great or it might be a hobby that you're mistaking for a business. A platform that you personally love and use every day might be solving a real problem or it might just be solving a problem you happen to have, which is not the same thing.
The other reason this is hard is that admitting a platform isn't working is genuinely painful, especially when you put real time and creative energy into building it. Founders are wired to be optimistic about their own projects because optimism is what carries you through the hard parts of building, but that same optimism becomes a liability when the project genuinely should be killed and you're using your optimism to avoid seeing it. The line between "this just needs more time" and "this is never going to work" is the hardest line in solo founding to draw, and most of us draw it wrong in both directions across our careers.
And there's a third complication that's specific to the Claude Code era, which is that the marginal cost of keeping a platform alive is genuinely low. The infrastructure runs itself, the site keeps serving traffic to whoever finds it, and the platform doesn't actively cost you much to leave online. That low marginal cost makes it tempting to just let dead platforms drift, which is fine on a per-platform basis but corrosive in aggregate because the attention you're spending checking analytics on dead platforms is attention you're not spending building new ones or investing in the ones that are actually working.
The signals that something is genuinely not working
The first signal I look for is whether the search trajectory is flat or declining over a multi-month window, because organic search is the only sustainable traffic source most of my platforms have, and a platform that isn't compounding in search after three to six months of consistent content effort is almost certainly never going to compound. Healthy platforms in my experience show a slow steady rise in impressions and clicks over time even when the absolute numbers are small, where the trajectory matters more than the level. Platforms that have been live for several months and are showing zero upward movement in Search Console aren't going to suddenly start working in month seven, and the data is usually clear enough to read honestly if you're willing to look.
The second signal is whether users who do find the platform stick around or leave immediately, because traffic without engagement is almost worse than no traffic at all. The way I check this is by looking at the bounce rate, the pages per session, and the time on site for the platform compared to other platforms I've shipped in similar categories. A platform where users land on a page, look at it for fifteen seconds, and leave without exploring anything else is a platform that's not delivering on whatever promise brought them there in the first place, and no amount of more traffic is going to fix the underlying problem. The fix is either to make the platform actually useful or to recognize that it isn't and move on.
The third signal is whether the platform is generating any revenue at all relative to what it should be generating at its current traffic level. The math here depends on the platform category but the general rule is that platforms with real product-market fit start showing some level of monetization even at low traffic, while platforms without product-market fit show essentially zero conversion even when traffic is decent. If a platform has been live for several months, has some level of traffic, and has converted essentially nobody to paying customers, that's not a marketing problem that more SEO would fix, that's a product problem that says the platform isn't delivering enough value to justify the price.
The fourth signal is whether you personally still believe in the platform after the initial excitement has faded, because the early enthusiasm of shipping something new will carry any founder through the first few weeks even on projects that turn out to be wrong. The honest test is how you feel about the platform at month three or four when the novelty has worn off and you're looking at the same dashboard and finding it boring. Platforms that you've stopped wanting to work on are usually platforms your subconscious already knows aren't working, and the conscious mind is just slower to catch up to what the gut already knows.
The fifth signal is whether the niche itself has changed in ways that make the platform less viable than it was when you started. Maybe Google's algorithm shifted in a way that makes your category harder to rank in. Maybe a competitor with serious funding launched a much better version of what you built. Maybe the audience moved to a different platform entirely. Any of these can turn a platform that was on a working trajectory into one that no longer is, and being honest about external changes is part of the discipline of evaluating your own work fairly.
What to do before killing it
Before declaring a platform dead, there's a checklist of things worth trying because some platforms aren't actually broken, they just haven't had the right push yet. The first thing to try is making sure the platform has the basics covered: clean SEO, proper sitemap, internal linking, fast load times, mobile responsiveness, and a clear conversion path from landing page to whatever the platform is selling. A surprising number of platforms that look dead from the analytics are actually just suffering from a fixable technical issue that's been quietly killing their growth, and an afternoon of cleanup can sometimes change the trajectory entirely.
The second thing to try is pushing harder on content and distribution for a defined period, where you commit to publishing X pieces of content over Y weeks and see whether the trajectory shifts. This works best when you've identified that the platform itself is sound but the distribution effort has been thin, and it gives you a clear up-or-out test where either the platform responds to the increased effort or it doesn't. The key is to set the time limit in advance and stick to it, because the alternative is open-ended hope which is how zombie platforms get created in the first place.
The third thing to try is repositioning the platform around a different angle or audience without rebuilding it from scratch. Sometimes a platform has the right bones but the wrong framing, where the same underlying product would work for a different target user or a different use case. Repositioning is cheaper than killing and rebuilding, and a surprising number of platforms get a second life from a different positioning that the founder didn't see on the first pass. The version of this that doesn't work is when you reposition repeatedly without commitment, which is just procrastinating on the decision to kill or commit.
The fourth thing to try is asking actual users why they didn't stick around, which sounds obvious but most founders never do it because it requires either having an email list of bounced users or being willing to reach out to people directly. The information you get from this is almost always different from what you assumed was the problem, and sometimes it points to a small fix that would have been hard to identify from analytics alone. Other times it confirms that the platform fundamentally doesn't deliver enough value, which is also useful because it gives you the honest data you need to make the kill decision with confidence.
How to actually kill it
When you've decided that a platform isn't working and shouldn't get more attention, the actual mechanics of killing it matter because there are good and bad ways to do this. The worst way is to just stop working on it without making any decision, which is how platforms become zombies that drift indefinitely while quietly costing you attention and infrastructure. The better approach is to make an explicit decision and execute it cleanly, which gives you closure on the project and frees up the mental space for whatever comes next.
The cleanest version of killing a platform is to leave it online but stop actively investing in it, where you maintain the basic infrastructure costs (which are usually small on self-hosted setups) and let the platform exist as a static reference while you focus on more promising bets. This is the right call for platforms that have some users or some SEO traction even if they're not growing, because the small amount of traffic they have is real and shutting them down entirely is overkill. The discipline is that you stop writing new content, stop building new features, and stop checking the analytics, treating the platform as effectively done while leaving the door open if something changes.
A more aggressive version is to fully sunset the platform, which means redirecting the domain elsewhere or just letting it expire, and is the right call for platforms that have essentially zero traffic and no realistic path to growth. Sunsetting is harder emotionally than just walking away, but it's also cleaner because it removes the temptation to occasionally check the dashboard hoping things have changed. The decision to fully sunset should be deliberate and infrequent, but when it's the right call it's the right call.
The version that almost no one talks about but that's worth considering is repurposing the platform's infrastructure for something new, where the codebase, the deployment setup, the operational tooling, and even some of the design system carries over to whatever you build next. This is one of the underrated benefits of running a portfolio of similar platforms on a consistent stack, where killing one platform doesn't actually waste the technical work you put into it because that work compounds across future platforms. The platform itself failed, but the infrastructure and the skills don't go anywhere.
The skill that compounds
The reason this matters as a founder skill is that the founders who can recognize failure quickly and respond to it well are going to massively outperform the ones who can't, especially in the Claude Code era where the cost of trying new things has dropped to the point where you can run more experiments than ever before. The bottleneck on a portfolio of platforms isn't the building, it's the judgment about which platforms to keep investing in and which to let go, and that judgment is genuinely a skill that develops over time with practice.
The mistake I see most often, including in my own behavior, is treating the kill decision as a moral failure rather than a normal part of building, where killing a platform feels like admitting you were wrong and continuing to work on it feels like persistence. The reframe that helps is that running a portfolio of platforms means most of them won't work, the same way an investor's portfolio means most of the individual bets won't return outsized gains, and the job isn't to make every bet succeed but to recognize quickly which ones are working and concentrate attention there. Kill decisions aren't admissions of failure, they're acts of focus.
The other reframe that helps is that the platforms you don't kill are stealing oxygen from the platforms that might actually work, which is the real cost of indecision. Every hour you spend tinkering with a zombie platform that's not going anywhere is an hour you didn't spend on the platform with actual signs of life, or on the new idea you haven't tried yet, or on the distribution work that would compound into your next launch. The opportunity cost of refusing to kill bad platforms is much higher than the emotional cost of killing them, and recognizing that asymmetry is most of what separates founders who eventually find something that works from founders who burn out on a portfolio of half-alive projects.
If you're staring at a platform right now wondering whether you should keep going or move on, the most useful question to ask yourself is whether you'd start this platform today if you didn't already have it. If the honest answer is no, that's usually your gut telling you something your analytics already showed but you weren't ready to read. And if the honest answer is yes, then commit to it harder rather than half-heartedly, because uncommitted effort is how platforms die quietly without ever getting a real shot.
