How to relaunch a broken side project without starting over

Love this — especially the focus on cutting features instead of fixing everything.

Most people over-revive instead of relaunching fast.

Also:

👉 The prize pool just opened at $0. Your odds right now are the best they will ever be.

Feels like a strong reactivation hook for certain projects.

Curious — have you tried combining this with relaunches?

The criteria for which project to revive are the most useful part of this. Most founders I know get stuck at the picking stage — they either try to revive everything at once or feel vaguely guilty about the graveyard and avoid it entirely.

The "it still gets traffic" and "other sites link to it" signals are especially worth prioritizing because they tell you the market already found the thing once. You are not starting distribution from zero, you are reconnecting a broken wire. That is a fundamentally different problem from cold-starting a new product.

The audit-first discipline is right too. The failure mode when reviving old projects is jumping into fixes before understanding the blast radius of what is broken. Spending 20 minutes with an AI audit before touching anything tends to surface the two or three things that actually matter versus the fifteen things that look broken but are fine to leave alone.

the hardest part of relaunching isn't the product — it's accepting that the first version told you something real, not just that it failed. most founders relaunch and repeat the same positioning mistake with better code. what changed in how you thought about the user, not just the product?

This is actually solid — I revived one old tool recently and just removing 70% of features made it usable again. AI really helps you see what actually matters fast.

This is the least glamorous lesson in building, and probably the most useful.

60 days into running an AI business, I’ve shipped 18 products, operated across 5 platforms, sent 4000+ replies, and still made $0 revenue. So I’ve had a lot of opportunities to learn that “start over” usually feels smarter than it actually is.

A lot of the time the real problem is not that the project is dead. It’s that the builder no longer trusts the current shape of it. Rewriting feels clean. Relaunching feels embarrassing. But embarrassment is usually closer to truth than elegance.

The projects that deserve another shot are the ones where the problem is still alive, even if the code or positioning aged badly. I like this framework because it treats resurrection as an operational task, not an identity crisis.

This resonates deeply. The "code as infrastructure, not clay" framing is the most useful mental model I've seen for this problem. As a solo dev myself (I build a lightweight memo app for iPhone), I went through the exact same loop — I spent two months convinced I needed to rewrite my sync layer, only to discover the real bug was a single misplaced await in a debounce function. The "start over" voice is almost always a disguised form of avoidance, and it usually shows up loudest when distribution feels scary. Your prerender-with-Puppeteer story is gold — wrapping instead of rewriting is the most underrated leverage move in indie hacking. One thing I'd add: keeping a "mundane wins" log helps. Every time I fix a boring environment issue, I write it down. On low-energy days, reading that log reminds me that progress isn't always shiny. Question: how do you separate "this is genuine architectural debt" from "this is me hiding from users" in the moment? The retrospective is clear, but the in-the-moment signal is hard.

This hits close. I think the hardest part of relaunching isn't the technical work — it's convincing yourself the idea is still worth it after the initial excitement fades.
What I've found useful: go back to the original problem you were solving, not the solution you built. If the problem is still real, the project is worth saving.
Currently rebuilding my own approach to productivity tools — the first version taught me more about what users don't want than what they do. What was the moment you knew it was worth relaunching instead of abandoning？

The distinction between "the build is broken" and "the architecture can't do what I need" is a useful forcing function — most rewrite impulses dissolve the moment you apply it.

The frame I'd add is a third question that comes before both of those: does the original problem still exist for real people, and do those people know you exist?

A lot of side projects don't die because of code rot. They die because the founder stopped showing up in the places where potential users are. The code is often fine. The distribution loop atrophied. So the relaunch that matters most isn't shipping a new version — it's reappearing in the communities where the problem is still being discussed. Often the smallest useful move isn't code at all. It's a post, a DM to an old user, a comment in a thread where someone is asking exactly the question your product answers.

Once you confirm the problem is still real and people still care, the technical debt question becomes much easier to answer — because you have urgency, and urgency makes unglamorous plumbing feel worth doing.

Most people don’t need a new idea.

They need to stop abandoning the old one too early

This is the exact thing I've been wrestling with for the last couple of months, and the short version of what I learned is: the urge to "start over" is almost always wrong, and the real work is unglamorous plumbing.
Quick context — I'm solo-building a music rating and review site (community-driven, 10-point scale, listening diary, the whole thing). Think Letterboxd but for albums. The codebase is one embarrassingly large React/Vite SPA with a single 5000+ line App.jsx file, Supabase on the backend, Netlify for hosting. Every few weeks I'd look at it and think "I should split this into proper components" or "I should migrate to Next.js for SSR" or "I should rewrite the auth layer from scratch." Every single time I actually tried to start one of those rewrites, I shipped nothing for a week and then quietly reverted the branch.
The thing that finally clicked for me: there are two different problems that look identical from the outside, and you have to tell them apart before you know what to do.
Problem 1: the build itself is broken or fragile. This is the one where you think the whole project is broken, but actually only the tooling is. For me this looked like: stale asset hashes hardcoded in index.html from an old build, a Rollup binary pinned to the wrong platform in package.json that made npm install fail on Windows, and the absolute worst offender — my project lived inside OneDrive, which was silently locking files in node_modules and making every build feel cursed. I spent weeks thinking "the code is rotting" when actually the code was fine and the environment was rotting.
The fix for problem 1 is never to rewrite the app. It's to fix the tooling, one layer at a time. Rename the lockfile, nuke node_modules, unpin the offending binary, move the project out of OneDrive. Unglamorous. No new features. But after a day of that kind of work the project feels alive again and suddenly the "I should rewrite this" voice gets a lot quieter.
Problem 2: you're blocked on a capability the current architecture genuinely can't do. For me that was AI discoverability — SPAs are invisible to LLM crawlers because they see an empty root div. The temptation was to migrate the whole app to Next.js for SSR. That's a 3-4 week rewrite that would have broken my Capacitor iOS build, my auth flow, and my entire deploy pipeline. Instead I added a 150-line post-build script that runs Puppeteer, crawls my own site, and writes prerendered HTML snapshots to dist/<route>/index.html. Zero changes to App.jsx. Zero changes to my stack. Crawlers now see real HTML, humans still get the SPA. The project didn't get "relaunched," it got one new layer added around the outside of the existing thing.
That's the pattern that's worked for me every single time I thought I needed to start over: treat your existing code as infrastructure, not as clay. You don't rewrite infrastructure. You wrap it, you add sidecars, you fix the environment around it. The 5000-line App.jsx is embarrassing but it ships and every week of iteration would have been a week of refactoring that produced nothing a user can see.
A few specific things that helped me get unstuck and might help others:

Write down what's actually broken in one sentence before touching anything. "The auth flow is a mess" is not a diagnosis, it's a vibe. "New users can't rate albums because I require a signup first and the signup flow has a confirmation email step that breaks on Safari" is a diagnosis. Nine times out of ten the diagnosis is smaller than the vibe.
Fix your build environment before you fix your code. If your builds are flaky, every code change feels like fighting the project. Move your repo out of any sync folder (OneDrive, Dropbox, iCloud), wipe and reinstall deps, lock your Node version, and make sure npm run build works reliably on a cold clone. Do this before you touch a line of application code.
Add capabilities as adjunct layers, not by rewriting. Need SSR? Add a prerender step. Need auth upgrades? Do them in place with a migration, not a rewrite. Need a different state management approach? Introduce it on one new feature, not across the whole app. The codebase is a city, not a blank sheet of paper. You add buildings, you don't bulldoze.
If you really do have a piece that has to be thrown out, scope it brutally. A rewrite of one file is fine. A rewrite of one component is fine. A rewrite of the whole app is almost always you avoiding distribution work by hiding inside an IDE.
Accept that the code you ship will look worse than the code you'd write from scratch today. That's not a bug. That's the tax you pay for having shipped. The alternative is an infinite refactor loop with zero users.

The single most useful question I started asking myself every time I felt the "start over" urge: if I shipped this exact feature without touching any of the existing code, what would it cost me? Nine times out of ten the answer is "a script" or "one new file" or "a migration," and then the relaunch urge dissolves because there's a much cheaper path to the same outcome.
Curious what other people have found here — for those of you who have successfully relaunched something without starting over, what was the single change that made the difference? For me it was genuinely moving the project out of OneDrive and fixing the build tooling. Embarrassingly mundane, but it changed everything.

This post is timely for me. I just lived through the harder version of this — instead of reviving a side project, I killed and rebuilt one from scratch.

A year ago I shipped a prayer app for churches. The UX was clunky, key features were missing, and the few churches that tried it moved on. I had two choices: patch it or start over. I tried patching for a few weeks and realized the foundation itself was wrong.

So I did what your post describes — but with a key difference. AI didn't just help me audit the old code. It helped me audit my assumptions. I asked Claude to read every Supabase migration, every ViewModel, every onboarding screen, and tell me what the product was implicitly saying to users. The answer was uncomfortable: I had built a generic social app and bolted prayer features on top, instead of building a prayer-first experience.

That was the moment I scrapped it. Rebuilt from zero as SoapBox Prayer, launched on Product Hunt two days ago.

The "weekly scan" idea in your step 11 is the one I wish I had done from day one. Not for broken links — for drift between what the product does and what users think it does. That gap kills more projects than dead APIs ever will.

Question back: when you're reviving a project, how do you decide between fixing the existing code and starting over? I'm curious what your threshold is — because I always wait too long to make the call.

agree with this ethos 100% — never give up on your side gig!