When to Start Over

One of the hardest decisions in building is knowing when to stop patching and start fresh. Starting over feels like failure. It feels like throwing away work. But there is a kind of start-over that is actually the fastest path forward — not because you failed, but because you learned enough to do it right the second time.

The Difference Between a Rough Patch and a Real Problem

Every project has rough patches — sessions where nothing works, features that take longer than expected, bugs that are frustrating. These are normal. They are not signs to restart. A rough patch is a temporary difficulty inside an otherwise coherent project. A real problem is different. A real problem is when the structure of the project itself is the obstacle — when every new feature you try to add fights against how the project was originally built. Real problems signal that the foundation has a flaw that patching will not fix. The key word is coherent. A project that is messy but understandable is still fixable. A project where you no longer understand why anything works the way it does is much harder to fix.

Here is a real example of the signal. Priya added five features to her quiz app incrementally. Then she tried to add a 'review your wrong answers' screen. Every approach she tried broke the score counter or the question flow. She spent two sessions on it. She asked AI for help and the AI kept suggesting changes to parts of the code she did not understand. She looked back at her build log. The quiz code had been patched seven times, each patch adding a small workaround to a previous workaround. The structure had become tangled. Her decision: start the quiz logic over from scratch, with the knowledge she now had from building it once. She wrote a new, clean prompt. She rebuilt in one session. The review screen worked on the first try. Total time lost: one session. Total knowledge gained: far more than she would have gotten from three more sessions of fighting the old version.

The Start-Over Checklist

Before you decide to start over, answer these questions honestly. 1. Do I understand why the current version works the way it does? If the answer is mostly no, starting over with a clearer design is often faster than fixing something you cannot read. 2. Have I been fixing the same area of the project more than twice? Fixing the same bug twice means you patched the symptom, not the cause. Fixing the same area three times usually means the design is wrong. 3. Does adding any new feature require touching five or more unrelated parts of the project? High interconnection means the architecture is tangled. New features should touch only the relevant parts. 4. Is the project still fun to work on? Persistent dread is sometimes your gut telling you that continuing is not the most efficient path. If you answer yes to two or more of these, a targeted fresh start is worth serious consideration.

How to Start Over Well

Starting over well means using everything you learned from the first version. Step 1: Write a new vision document before touching a tool. You know far more about this project now than you did the first time — use that knowledge. Answer the five questions from Lesson 2 with the depth of someone who has already built a version. Step 2: Write a new strong prompt that incorporates what you learned. Include the things that worked in the old version and explicitly exclude the patterns that caused problems. Step 3: Do not look at the old code while building the new version. Reference your build log, not the code itself. Looking at tangled old code often leads to copying its flaws. Step 4: Move the old code to your archive folder — do not delete it. It may contain working pieces you can reference if needed. Step 5: Build the new MVP first, confirm it works, then add features incrementally, just as you did before.