How to Finish Things: Notes from Two Years of Solo Game Development

Every unfinished project teaches the same lesson with a different accent: you didn’t fail at coding, you failed at scope. Ember & Vow took two years, and at least four times I saved it by deleting features I loved.

The 80% rule, inverted

We’re told features take longer than estimated. The inverse matters more: removal is instant. The moment you cut a mechanic, every bug it would have had, every asset it needed, every edge case it implied — all gone, retroactively. Cutting is the only productivity technique with zero implementation cost.

Scope is a design skill

The best design decisions in my game were deletions. The monastery originally had five districts; it has three. The dialogue originally had a branching moral system; it became a straight line with better writing. Players praised the “focus” — they were praising what I removed.

When a client project runs over, the instinct is to work harder. The professional move is to renegotiate the shape of the thing: same promise, smaller surface.

The discipline of done

“Done” is a contract with a date. My rules from the final six months:

1. No new mechanics after content lock. Only tuning and fixes.
2. Every cut gets written down in a single file called GRAVEYARD.md. It kills the zombie conversations (“we could add it back later”) because the reasons for cutting are on record.
3. Ship the worst acceptable version. Polish after launch has feedback; polish before launch has only anxiety.

The takeaway

Finishing is a skill you can only learn by finishing. The graveyard file is now in every project I start — client work included.