When to Start Over vs. Keep Patching
There's a moment in every project where you have to decide: is this a bug I fix, or is this the building telling me the whole ground floor is wrong?
I have gotten this wrong more times than I've gotten it right. My default is to patch. Something breaks, I describe it to the AI, the AI proposes a fix, I nod like I understand, and we move on. Another thing breaks two days later that turns out to be connected to the first thing. Patch. Another. Patch. Eventually I'm on patch number eleven and I realize I've built a Jenga tower where every block is labeled "temporary."
That's the moment. That's the tell.
The signs it's time to start over (or at least tear out a big chunk):
- You're fixing the same kind of bug more than twice.
- You can't explain, in one sentence, what a page or a feature actually does anymore.
- You're afraid to touch a file because you don't know what will fall over.
- The AI keeps suggesting fixes that feel like duct tape on duct tape.
- You catch yourself writing prompts that begin with "without breaking anything else..."
The signs it's actually just a bug:
- One clear error message, in one clear place.
- You changed something recently and it broke right after.
- The fix, once found, feels obvious in hindsight.
- Nothing else in the app feels shaky.
Here's the thing nobody tells you: starting over is almost always faster than you think. The first time through, you didn't know what you were building. Now you do. The second attempt is not "throwing away weeks of work" — it's cashing in weeks of learning. You'll rebuild the important parts in a fraction of the time, and you'll leave out the three features you added that nobody (including you) ever actually wanted.
I've done full restarts on two of my projects. Both times I dreaded it. Both times I was on the other side within a couple of days, wondering why I'd waited so long.
A rule that has served me well: if I've spent more than a day trying to fix one thing and I'm no closer, it's not a fix problem. It's a foundation problem. Stop. Zoom out. Ask the AI: "Given everything you know about this project, would you build this the same way if we started today?" You'll be shocked how often the honest answer is no.
You are allowed to throw things away. In fact, learning to throw things away is one of the most important skills in this whole process. The most experienced developers I've read about talk about "murdering your darlings" — killing the features you love because they're not serving the whole. That's not failure. That's taste.
Your project is not a monument to every decision you've ever made. It's supposed to be the best version of what you're trying to build right now. If the fastest way to that version is to bulldoze half of it, bulldoze half of it.
What I'd tell someone in my shoes: the sunk cost is already sunk. It's sunk whether you keep patching or start over. The only question is which path gets you to something you're proud of faster. Nine times out of ten, the answer is the one that scares you more.