Solo Dev Scope: How to Finish the Game You Started

Solo projects stall because the remaining work is unbounded rather than large. The fix is a finish list: a closed, written set of tasks that defines done, with everything else moved to a separate list you are allowed to ignore. Nothing gets added to the finish list once it is set.

Why this matters

Starting is easy and finishing is not. The first weeks produce visible progress, and the last stretch produces work nobody sees.

That stretch is where most solo games quietly end. Not through a decision to stop, but through the project becoming permanently almost finished.

The causes are structural rather than personal, which means they respond to structure.

Why solo projects stall at 70 percent

Three things happen at roughly the same point.

The visible work runs out. Early work produces screenshots. Late work produces bug fixes, store assets, and edge cases, none of which feel like progress.

The list stops shrinking. Every task completed reveals two more. Without a closed list, the end genuinely is not getting closer.

Motivation shifts. The idea has been explored, the interesting problems are solved, and what remains is execution.

A project without a closed list of remaining work cannot be finished, only abandoned. Closing the list is the whole job.

Cutting to a shippable core

Cutting is the work, and it is uncomfortable because it means abandoning things already built.

Run this exercise on paper, away from the project.

1. Write the one sentence describing what the player does. If you cannot, that is the finding.
2. List every feature currently in the game, built or planned.
3. Mark each one as essential to that sentence, supporting, or neither.
4. Cut everything in the third category, including finished work.
5. Cut half of the second category.

Cutting finished features is the part people resist. The time is already spent either way, and keeping something built early because it was expensive is how a game never ships.

Treat sunk cost plainly, as in Update, Pivot, or Shut Down Your Game.

The feature freeze, and how to hold it

A freeze is a date after which no new features enter the project. Only fixes, content, and polish.

Solo developers find this harder than teams, because there is nobody to say no.

Three mechanisms that work without another person.

• A written freeze date, visible where you work.
• An ideas file. Every new idea gets written down immediately and then dropped. Writing it satisfies most of the urge and keeps a genuine record for the next project.
• A weekly check. One question: did anything get added this week that was not on the list. If yes, remove it now rather than later.

The ideas file matters more than it sounds. Most solo scope creep comes from good ideas arriving at bad times, and the goal is to capture them without acting.

Building a finish list, not a wish list

The difference is that a finish list is closed.

Write down everything that must be true to ship, in one document, in one sitting. Then stop writing.

A workable structure:

Estimate each item, total it, and add half again. The result is your real remaining time, and it is usually a shock. That shock is useful, because it is the point at which cutting becomes easy.

New items will appear. Add them only if they block shipping, and write the rest in the ideas file.

Dealing with the boring last 10 percent

The final stretch is store assets, icons, edge cases, and settings screens. It is unrewarding and it is not optional.

Two techniques help.

• Batch it. Do all the store assets in one session rather than spreading them across weeks. Context switching is what makes this work feel endless.
• Timebox it. Give the icon four hours rather than an open-ended search for the perfect one. Good enough genuinely is, and it can be updated after launch.

Do the compliance items first, not last. Discovering an account deletion requirement or a missing privacy policy on submission day is the most common cause of a delayed launch, and the requirements are in Why Games Get Rejected.

When to bring in help for one slice

Solo does not have to mean alone for everything.

The strongest candidates for a small paid engagement are the ones where you are slow and somebody else is fast.

1. Art, especially a consistent icon and store screenshot set.
2. Audio, which is quick for a specialist and slow for everyone else.
3. A performance pass, if the game runs poorly and you do not know why.
4. Store assets and localisation, both bounded and easily specified.

The test is simple. If a task would take you three weeks and is a known quantity for somebody else, buying it back is usually the cheapest week you will spend on the project. The briefing approach is in How to Brief an Art Outsourcer.

What we would do

Set the freeze date first, before cutting anything. A deadline makes the cutting decisions obvious, and without one the exercise stays theoretical.

Then write the finish list in one sitting and treat it as closed. Estimate it, add half, and cut features until the total fits the time you actually have.

Ship something imperfect. A released game that can be improved is worth more than a perfect one that never appears, and almost everything you are worried about can be patched.

The short version

• Solo projects stall because the remaining work is unbounded, not because it is large.
• Cut against a one-sentence description, including finished features.
• Set a written feature freeze date and keep an ideas file for everything after it.
• Write a closed finish list in one sitting, estimate it, and add half.
• Batch and timebox the final stretch, and do compliance items first.
• Buy back the slices where somebody else is fast and you are slow.

Set a freeze date this week, then write your finish list in one sitting. If one slice is what stands between you and shipping, tell us which.

Related reading: Game MVP Feature List: What to Cut, Changing Scope Mid-Project, and 12 Free Tools Solo Devs Use to Ship Faster.