The Ninety-Ninety Rule: Why Your Indie Game Stalls at 90% Done

You've been 90% done for four months.

The core loop works. The art style is locked. You've shown friends a build and they didn't hate it. But every Friday the game is still 90% done, and some Fridays it's 88% done because you tore out a system nobody asked you to rewrite. The last 10% of your indie game has turned into its own project — bigger than the first 90%, and a lot less fun.

You are not the problem. The last 10% is. By the end of this post you'll know how to tell a normal polish tail from the 90/90 death zone, and you'll have a five-step plan to get out.

What you need before you start:

• A project with playable end-to-end content (you're past vertical slice).
• One human willing to look at a Friday build.
• A calendar you actually open.

---

1. What the ninety-ninety rule actually says (and why indie games hit it harder)

The ninety-ninety rule is older than most indie devs. In 1985, Tom Cargill at Bell Labs put it this way: the first 90% of the code accounts for the first 90% of the development time; the remaining 10% of the code accounts for the other 90% of the development time. Jon Bentley printed it in his "Programming Pearls" column in Communications of the ACM. It was a joke about software estimation. It stopped being a joke around the time you shipped your first game jam and realized the "polish week" took two months.

Game developer Tomas Sala, who spent years shipping Bloodmead, puts it the same way on his dev podcast:

"It's often being said that last 10% takes as long as the first 90% or something like that, there is some kind of fun little metric that gets played out."

Indie games hit the rule harder than the rest of software, for three structural reasons:

• There's no QA team. Nobody is loading your build and breaking it for you. Every bug you find, you found because you looked.
• There's no producer. Nobody is drawing a line that says "this is the scope and after this line we ship." You draw that line. You also argue with it.
• There's no external deadline. A studio has a fiscal year and a publisher. A solo dev has a ship date on a sticky note, and the sticky note is the thing that slides every week.

One person is holding the whole thing. That's why your last 10% isn't really 10%. It's a different project wearing the same codebase.

2. Five patterns that tell you you're in the 90/90 death zone

Before the steps, the diagnostic. Skim these and find your pattern. You probably have more than one.

Pattern 1: The restart loop. You open the project, read the code you wrote six months ago, cringe, and start rebuilding the system. Not fixing it. Rebuilding it from scratch in a cleaner way. The new system takes three weeks. It does the same thing as the old one. You feel great for a day, then you open the next file you wrote six months ago.

Pattern 2: The polish loop. Every Friday you fix five things. Every Friday five more appear. The game doesn't get worse. It also doesn't ship. One indie dev put it plainly on a game-dev blog: "Every indie developer knows the feeling: your game is almost done, yet there's always something else to tweak, adjust, or enhance. You find yourself stuck in an endless loop of improvements."

Pattern 3: The dream-game escape. You start thinking about your next project during the shower. You outline it in your notes app. You catch yourself watching devlogs for games in the genre you wish you were making. From a real r/gamedev post: "I want to finish this game ASAP because I'm so tired of it so I can create my next super exciting dream game."

That's not inspiration. That's the back half of your brain trying to get out of the room.

Pattern 4: The dread open. Opening the IDE feels physically bad. The dev who made Blood and Mead described it like this on his podcast: "I got to the point where I was going to sleep with a feeling of dread, dread of not being able to bring the project together and the dread of failing."

Pattern 5: The disappearing witness. Your devlog stopped. You haven't shown the game to another human in six weeks. Nobody is asking about the build. You tell yourself you're "heads down" — but the truth is the game has gone invisible, and it's a lot easier to not ship something nobody expects.

If you recognized three or more of these, you're not in the last 10%. You're in the 90/90 death zone. That's a structural problem, not a character flaw. Keep reading.

3. Why the last 10% is not a willpower problem

Every listicle about finishing your indie game tells you to grind harder. That is the single worst advice for this specific phase.

The last 10% breaks under isolation, not under low effort. You're already pouring effort in — you wouldn't be reading this if you weren't. The effort is just hitting a structure shaped like Swiss cheese.

Three structural reasons the endgame collapses when you're alone:

• The bug tail is invisible without a second loader. You know every corner of your game. You stop seeing the softlock because your muscle memory walks around it. Somebody else loads the build, hits the softlock in thirty seconds, and suddenly the game is broken again. That feedback never arrives if nobody else is loading the build.
• "Done" has no external definition. A publisher sends a checklist. A producer cuts features. A solo dev negotiates "done" with themselves every Friday — and loses, because the only person arguing for shipping is the same person who has to ship.
• Real life wins more often. Not because you're lazy. Because nobody else is counting on Friday's build. An hour pulled out for family, errands, sleep — nobody notices. So every week the hour gets pulled out a little sooner.

You're not lazy. You're unsupported.

Even legendary teams hit this wall. Team Cherry's Ari Gibson said of Silksong: "If I don't stop drawing, this is going to take 15 years to finish." Silksong spent seven years in the refinement phase — not because the team was undisciplined, but because for most of that stretch the project had no external forcing function. A two-person studio with zero witnesses is structurally identical to a solo dev in the 90/90 zone. It just happens to be full of talent.

The fix isn't more discipline. The fix is a system that puts a human on the other side of your Friday build.

4. Step 1 — Declare the scope cut

Open a text file. Call it ship.md. Make two columns: Ship list and Someday list.

Take every open task in your project — every feature, every bug, every "nice to have," every Trello card, every scrap of paper — and force it into one of those two columns. There is no third column.

Rules:

• Ship list is hard-capped at 20 items. If you have 47, you haven't cut yet. Cut again.
• Anything that feels "ambiguous" goes on the someday list by default. Prove it belongs on the ship list.
• "But players will hate it if I cut this" is not proof. It's the scope-creep voice. Cut it anyway. Write it on someday. If it matters, it becomes a patch.

If you've never done this cold, do Scope Creep Is Killing Your Game first. This step is the structural ancestor of every other step in this post. You cannot ship a list you haven't written.

5. Step 2 — Set a shipping window you can't silently move

Not a date. A window. Two weeks wide.

"I'm shipping in Q3" is useless — nobody knows when you broke it. "I'm shipping between October 14 and October 28" is testable. Somebody can ask on October 29 whether you shipped, and you have to answer.

Write the window somewhere public:

• A devlog post with a headline date.
• A pinned Discord message.
• A tweet.
• A Steam coming-soon page (this one is the hardest to move silently — Valve shows the date to players).

The point isn't marketing. The point is that at least one human outside your head knows when you said you'd be done. That's the forcing function. A private deadline on a sticky note is invisible. A public window is a commitment that will cost you face to move.

Mike Bithell gave a whole GDC talk in 2015 called "Indie Polish: Making the Most of the Last 10%" — the entire premise is that the final 10% is its own discipline and needs its own plan. Game Developer magazine quoted him saying he'd "spent a lot of time thinking about how you can make the most of the last ten percent of your development time." He didn't say "grind harder." He said plan it differently. The public window is step one of planning it differently.

6. Step 3 — Install the Friday build ritual

Every Friday, you do three things:

1. Push a build of whatever you have.
2. Show it to one specific person.
3. Get one sentence back.

That's it. That's the ritual.

What to show: a build that boots and completes one loop. Not polished. Not the full game. Running. If last Friday's build booted and this Friday's doesn't, you just learned something about your week.

Who to show: one specific person on a specific day with a specific ask. Not "post it in a Discord server." Discord servers are not a witness — they are a diffusion of responsibility. A witness is a named teammate, an accountability partner, a playtester who committed to loading every Friday build, or a small group that meets every Friday. One of them.

What you're measuring: whether the game runs end-to-end better this Friday than last Friday. Not "is it polished." Not "is it fun." Does it boot, does the loop close, is it monotonically improving.

A dev on the Home Team podcast put it better than I can:

"Having to maintain a schedule and present on a weekly basis not only helps with motivation but it also shows that there are people who want to see you succeed."

Same dev, later in the same episode:

"On my own I couldn't release anything finished. After joining I got to work on a number of games with so many people."

That's not a motivation quote. That's a structure quote. The person is saying: put somebody on the other side of the build, and the build ships. If you don't have a Friday witness yet, Accountability Circles walks through the small-team ritual that installs one.

7. Step 4 — Cut the bug tail with triage, not heroics

Somewhere in your repo you have 140 open bugs. Maybe 400. Most of them are real. Almost none of them are ship-blockers.

Triage into three buckets, once:

• Ship-blocker. Crashes. Corrupt saves. Can't-progress softlocks. Build doesn't compile on a customer's machine. These block the window. Fix them.
• Annoying but ships. Visual glitch. Minor softlock with a workaround. Controller rebind that saves weird. Log it, document the workaround, ship. Patch later.
• Someday. Design debt. "It would feel better if." Everything that's actually a feature wearing a bug costume. Someday list. Possibly never list.

Rule: before the window, you only fix ship-blockers. That's it. The "I'll just fix this one quickly" bug is how Fridays disappear — log it and move on. Nobody who shipped a good game shipped it because every bug was fixed. They shipped because every ship-blocker was fixed.

8. Step 5 — Make the ship decision with a one-page checklist

Before the window opens, write a "done means" checklist. One page. Five to ten items. Here's the shape:

• Every Ship list item is ✅ or moved to someday.
• Every ship-blocker bug is ✅.
• The build boots on three different machines.
• Store page copy, screenshots, trailer are uploaded.
• Demo completes end-to-end without a crash on a fresh install.
• Credits file is current.
• Build size is under the platform limit.

Done means "every item on this checklist is checked, OR moved to someday." That's the definition. That's the only definition.

When you hit it, you ship. Even if it doesn't feel perfect. Especially if it doesn't feel perfect — the feeling of "not perfect" is what the last 10% does to your brain, it is not a signal about your game.

Paul Valéry: "A work is never finished, only abandoned." Back to Silksong: without a checklist, Gibson's "stop when it feels right" worked for four years, then it didn't. You don't get to escape this with taste. You escape it with a list.

9. Common pitfalls in the last 10%

• Pitfall 1: Restarting the project in a new engine. If you've hit the endgame wall, Godot won't save you. Unity won't save you. Unreal won't save you. Cadence will save you. The engine is not the problem and moving to a cleaner codebase doesn't make you past the 90/90 mark — it puts you back at 30% on a different codebase.
• Pitfall 2: The infinite polish pass. If every "final" polish pass generates a week of new polish, you are not polishing — you are hiding. Stop. Ship. Polish in a patch. The game does not get better after the fifth "final" pass. You just get tireder.
• Pitfall 3: Hiding the game until it's "ready." The game will never feel ready in isolation. That's what isolation does. Show it ugly. Show it broken. Somebody else's eyes are the only way "ready" becomes a real word again.
• Pitfall 4: Grinding solo through the dread. If opening the IDE feels bad for two weeks straight, you're not working harder — you're working alone. More hours of dread will not produce a shipped game. A witness by Friday will.

All four pitfalls come from the same place: there is nobody else in the room. The fix is always the same: put somebody in the room.

10. What to do next

If you're past vertical slice and stalling, start here:

• How to Finish Your Indie Game: The Complete Guide — the full pillar context for everything above.
• Scope Creep Is Killing Your Game — how to write the ship list and the someday list without lying to yourself.
• Accountability Circles — the weekly-ritual structure that gives you a Friday witness.
• The Vertical Slice Protocol — if you're actually earlier than this post assumes, go prove the game works first.
• Why 90% of Indie Games Die in the Idea Phase — the sibling 90% problem that lives at the other end of the project.

And the honest part of the CTA: the last 10% doesn't need more grit. It needs someone counting on Friday's build. A teammate who actually loads it. A structure where "done means" is enforced by more than one brain. Clowdr is the place that's built around that — a team, not a family. Structured cadence, retained rights, shipped credits that exist because the games ship.

If the Friday build problem is your problem, sign up for Clowdr →. Fifty bucks a month. First fifty members free for two months. Teammates who count on you by Friday, which is the only variable in this post that actually moves the last 10%.