The answer in brief

Creatives restart old projects because beginnings offer control, novelty, and relief from the hard decisions near completion. Rebuilding feels productive, but it often resets the evidence to zero. Freeze the core rules, define one finish line, and allow changes only when they are necessary to make that version work.

Why does restarting feel like progress?

The beginning of a project is generous. Every choice still seems possible. The ending is demanding because possibilities must become decisions.

When a project reaches the point where it needs testing, correction, coordination, or release, rebuilding the foundation can feel cleaner. You can rewrite the opening, redesign the rules, rename the characters, replace the software, or announce a new edition. Activity returns, and so does the emotional lift of invention.

But the final page is still blank.

In the book, I describe a science fiction role-playing game my friends and I created as teenagers. We wrote a roughly 300-page rulebook and tested it at conventions and with experienced gamers. The game worked. Yet it remained essentially a first-draft printout, waiting for writing, illustration, publishing knowledge, and the discipline to close the gaps.

Decades later, someone occasionally picks it up, changes a rule, or adds a page. That repeated attention has not made it finished.

What restart pattern should you look for?

A restart pattern usually has a trigger. The current version becomes uncomfortable, and a reset restores the feeling of competence.

Common triggers include:

  • Feedback exposes a structural problem.
  • A collaborator leaves or stops responding.
  • A new tool makes the current workflow feel old.
  • The project needs boring documentation or packaging.
  • The ending is weaker than the opening.
  • Release creates fear of judgment.
  • The creator can imagine a better version faster than they can repair this one.

The trigger matters because the new version may encounter the same obstacle. If the actual problem is missing ownership, a rewritten first act will not solve it. If the actual problem is fear of public response, new color grading will not solve it.

How do you distinguish repair from rebuilding?

Repair changes what blocks the defined finish. Rebuilding changes the definition of the project.

If a test reveals that players cannot understand a rule, clarifying that rule is repair. Replacing the entire system because the clarification feels inelegant is rebuilding.

If a scene fails to communicate a needed story turn, editing or reshooting that scene may be repair. Adding a new character, location, and subplot may be rebuilding.

Ask one question before approving a change:

What specific acceptance condition does this change help us meet?

If the team cannot name the condition, the change belongs in a later-version file.

What happened when the operating pieces stayed unfinished?

The game project expanded into a larger business plan. We wanted to raise money, hire people to improve the book, become a reseller, advertise nationally, build an online shop, and fulfill orders through a local distributor.

Individual pieces moved. An artist completed an advertisement. A magazine placement was arranged. Friends were prepared to order. A catalog and website were started.

But the whole path did not close. The people producing the catalog and site left the effort. Conflict grew inside the group. Money disappeared from a shared account. An order reached the post office box, but the system could not reliably retrieve and fulfill it.

The lesson is not that the original idea lacked value. The lesson is that an idea can demonstrate interest and still fail because the completion system does not hold.

How do you freeze a version without killing improvement?

Name the version and give it an acceptance condition.

For example, Version One may include only the rules required for one complete session, one setting, a limited character set, and printable files another person can use without the creator in the room.

Then create two lists:

  • Required before release
  • Candidate for a later version

The first list should contain defects or omissions that prevent use. The second can hold expansions, refinements, new features, and better ideas. The later-version list protects creativity by proving ideas are not lost. The release list protects completion by refusing to absorb them now.

What is your restart-pattern diagnosis?

Review the last three times you reset a project.

  • What stage had the project reached?
  • What uncomfortable task came next?
  • What reason did you give for restarting?
  • Did the new version solve that task or postpone it?
  • Which parts were rebuilt despite already working?
  • What would a repair-only path have looked like?
  • What is the smallest fixed definition you can finish now?

Choose one frozen version and prohibit foundation changes until it is delivered or definitively canceled. If you cancel it, write the reason and preserve what was learned. Do not let it drift back into indefinite rebuilding.

The project does not need endless rescue through reinvention. It needs one version that reaches the last page.

Next production note

Freezing a version is easier when the version is small enough for the available team to carry.

Continue to: Build the Smallest Version That Can Be Finished

Notes From the Director Learn the craft. Build the system. Make the film.

Source note

This article is adapted from No One Gives a F Until It's Done, PDF pages 13-18. Wayne's Galactic Battles and early online game-store experience provides the firsthand account of repeated rebuilding and unfinished delivery.