Why you keep rewriting your project from scratch

A rewrite keeps the part of the project that was fun — the first weeks, when anything was possible — and quietly drops the part that was not: the decisions, the launch, the asking strangers to care. You are not rebuilding the app. You are rebuilding the opening act and replacing the ending with a blank page.

The fresh start also resets every obligation without ever closing one. Version one's backlog, its half-read feedback, its embarrassing scope — none of it is rejected, so none of it can hurt. It is simply left in another directory, which becomes one more open repository in the pile. This is why the rewrite loop and the too-many-projects problem are the same problem: every v2 mints a v1.

The agent era sharpened all of this, because a new chat has no memory of your last failure. The model does not know version one stalled, so it never hesitates, and a collaborator with infinite patience and no memory is the perfect accomplice for starting over.

Before any rewrite, one written paragraph: what version one failed to do, and what specifically changes in version two so that failure does not repeat. Real answers look like: the data model cannot support the one feature that mattered, the platform choice is dead, the first version solved the wrong problem for the same people. Fake answers sound like: cleaner, modern, better structured, proper architecture this time.

If the paragraph cannot name a structural cause — something where the old foundation, not the old effort, is the constraint — the rewrite is a mood, not a decision. A mood gets deleted and the work goes back into version one, because version one is closer to shipping than any new directory will ever be.

This audit also catches the inverse mistake. Some codebases really are past saving, and the honest answer to which-old-repo-is-worth-finishing is occasionally none of them. The point of the paragraph is not to forbid rewrites. It is to force the rewrite to say what it is for, in writing, before the delete key comes out.

The loop continues because rewrites are free: nothing is dated, so nothing can be failed. So a rewrite gets a Gate, and the Gate encodes one rule — the new attempt has to beat the old one to a ship. Version two ships its first working flow by a date, or version two is KILLED and the work returns to version one. Version one is archived only on the day version two actually ships something, not the day it is created.

The Default does the enforcement. If the date arrives and no decision has been recorded, version two closes as KILLED by silence — the same mechanism that kills any other stalled Gate. A fresh start that cannot motivate itself to a shipping date within a few weeks was never a rewrite; it was a new toy with a serious name.

This is what converts the loop into a ledger. Each regeneration now spends a dated, closeable commitment instead of minting an undated one. After two or three cycles the pattern is on the record in your own words — and that record is usually the thing that finally ends the loop, because the pattern is no longer invisible.

The machinery above fits in a short paste: the audit paragraph, a ship-by date for the new attempt, and an archive rule for the old one. What makes it hold is that the date acts whether or not you ever record a decision — which is exactly what the current loop never has.

ShipGates runs this way itself: the business is built and operated end to end by AI agents on NanoCorp, and the free scanner below turns a rule set like this into dated Gates with Defaults — so the next fresh start costs a verdict instead of just another directory.