The short answer
Solo game devs do not fail at code. They fail at scope. Almost every dead indie project we have ever heard about was killed by the same loop: start something small, get excited, add a "just one more" feature, then another, then another, until the finish line moves out of sight and one Saturday you stop opening the project. The skill of finishing is not technical. It is the skill of deciding what your game is not.
The good news: this is the most fixable problem in solo game dev. It is also the one with the highest leverage. Doubling your shipping rate is worth more than doubling your coding ability.
Why it happens (and why it is not your fault)
Mid-build, a new idea will always feel more exciting than the half-finished thing in front of you. This is structural, not a discipline problem. The half-finished thing has bugs, half-rendered sprites, placeholder text, and a known set of things still to do. The new idea is a perfect imaginary version of itself, with none of the boring parts implemented yet.
So you switch. Or you fold the new idea into the current project, telling yourself it is "just one more system." Either move kills the original timeline. After a few cycles of this, the project becomes mathematically unfinishable in any reasonable horizon, and the visit-the-project decision starts to feel like a chore. So you stop visiting it. The folder sits.
This is not laziness. It is a totally rational response to a project that quietly turned into something too big to finish. The thing to fix is not the maker. It is the project's scope.
The patterns that kill projects
From watching our own and others' dead projects, the same patterns show up over and over:
- "While I'm at it" syndrome. "While I'm building the player controller, I might as well add a stamina system." Each addition is small in isolation. The bill adds up brutally.
- The save system trap. "Saving and loading is a basic feature, I should add it now." Saving a class of game data robustly with migration is days of work that does not visibly move the game forward.
- The settings menu. "Just a basic options screen." Then key rebinding. Then audio sliders. Then resolution. Then a settings save file. The settings menu is bigger than the game.
- Original art and music. "I'll get to the placeholder art later." Months of "to do later" art and music end up adding up to the same time as the rest of the game combined, by yourself, with no specific deadline.
- Procedural generation. "Instead of designing 10 levels, I'll generate infinite levels procedurally." Procedural systems are weeks of work that almost never produce levels as good as a designed handful.
- Multiplayer. Adding multiplayer to a game that does not have it is not adding a feature. It is starting a different project.
Notice the pattern: each of these feels reasonable in isolation. Each one quietly doubles the project. Three of them stacked turns a 12-hour project into a 12-month project. Most solo devs never see that math because they add features one at a time without keeping a total in their head.
The fix: write the scope down, make it a contract
The single intervention that works is to write the scope of your game down before you write any code, in a moment when you are not emotionally committed to a half-finished project, and treat that document as a contract with yourself.
The contract has to include:
- A one-sentence pitch. If you cannot say what your game is in one sentence, the game is not designed yet, it is a vibe.
- Exactly what the player can do. List the verbs. Move. Jump. Shoot. Solve. One or two verbs is a strong first game. Four or more is a warning sign.
- The win condition. One sentence.
- The lose condition. One sentence. Or explicitly: there is no lose state, this is a cozy game.
- The content budget. Real numbers. How many levels, how many enemy types, how many pickup types. Smaller than feels worthwhile.
- A ship date. If the date arrives and the game is not done, content gets cut. The date does not move.
- An "out of scope" list. Explicit, written. Multiplayer, save system, settings menu, original music, procedural generation, more levels, more enemies, alternate endings. Whatever you are not building. The list is the point. Anything not written on the contract or its scope is out.
When the inevitable new idea shows up at hour 20 of the build, you do not argue with yourself. You write the new idea on a "version 2" list and you go back to building the contracted game. The version 2 list is not a graveyard, it is the sequel.
A free tool that does this for you
We built one. It is called the Pixeldex scope-lock tool, and it is free, in-browser, no account, no signup.
You fill in the pitch, the player verbs, the win and lose conditions, the content counts, a ship date, and an "out of scope" cut list (the heavy scope-creep traps are pre-selected as cut by default). A live "scope meter" tells you whether your current plan is TIGHT, AMBITIOUS, or TOO BIG, based on how much you are trying to do and how many of the heavy traps you have left in scope rather than cut. The tool actively pushes back if you try to keep multiplayer and a save system in scope at the same time as 5 player verbs and 15 levels.
At the end you get a printable plain-text scope contract you can save, plus a ready-to-paste Claude prompt that turns the locked scope into a build order, with explicit "do not suggest anything from the out-of-scope list" instructions.
Your contract is saved in your browser and survives a refresh. There is a "Start fresh" button when you want to wipe it.
Practice finishing on something tiny first
If you have a graveyard of unfinished projects, the highest-leverage thing you can do this weekend is not to start project number 15. It is to finish a tiny game, any tiny game, just so your brain remembers what finishing feels like. After one finish, the next finish gets easier. After three finishes, you know you are someone who ships.
For that exact purpose, the shortest finish line on Pixeldex is the 2-hour Godot Breakout walkthrough. It is a real, complete brick-breaker game, scoped tight on purpose, four 30-minute steps, every Claude prompt inline, ends with a web build uploaded to itch.io. Two hours of focused work and you have a finished game with your name on it. That is the medicine.
It is not a discipline problem
If you are reading this and recognise yourself, please do not take from this article that you are lazy or undisciplined. You are not. The problem is structural, the fix is environmental (write the contract; pick the smaller scope), and people who do this for a living have to fight the same pull all the time. The difference between someone who ships and someone who does not is rarely willpower. It is whether they decided what their game was not, in writing, before they started.