Cut or Polish: A Decision Framework for Solo Devs

When your indie game scope is too big, decide what to cut by testing each feature against four questions: does it serve the core loop, will players see it in the first hour, is it nearly done, and does it appear in your trailer? Features that fail most of them get cut or simplified. The rest earn polish.

Why "cut or polish" is the real question

Every solo project reaches a point where the list of things to do is longer than the time left. At that point you are not choosing what to build. You are choosing where your remaining hours go.

Polish and cutting are two sides of the same budget. Every hour spent on a feature nobody will notice is an hour taken from the part players touch every minute.

You do not finish a game by doing everything. You finish by deciding, out loud, what you will not do.

The four-question test

Write every unfinished feature on its own line. Then answer these four questions for each, yes or no.

1. Does it serve the core loop? If players would do the main action without it, it is support, not core.
2. Will players see it in the first hour? Late-game content matters less if most people never reach it.
3. Is it more than 70 percent done? A rough threshold, but nearly finished work is cheap to complete.
4. Would it appear in your trailer or store page? If it sells the game, it earns its place.

Count the yes answers. That number tells you which pile the feature goes in.

Be strict with the second question. If you have no data on how far players get, assume most of them stop well before the end. That is true of most games, and it keeps late content from eating your polish time.

Sorting the results

The simplify pile is where most of the savings hide. A crafting system can become a short recipe list. A branching story can become one path with a few choices. A level editor can become hand-made levels.

Making cuts without breaking the build

Cutting in Unity is safer when you can switch features off rather than delete them right away. A simple flag in a ScriptableObject keeps the code around while you test the game without it.

[CreateAssetMenu(menuName = "Config/Feature Flags")]
public class FeatureFlags : ScriptableObject
{
    public bool crafting = false;
    public bool dailyQuests = false;
    public bool photoMode = false;
}

Check the flag where the feature starts, play the game for a day without it, and see if you miss it. Most of the time you will not. Then delete the code properly.

Our post on ScriptableObjects for game config covers this pattern in more depth.

Where polish pays off

Polish has the biggest effect on the things players touch constantly. Put your remaining hours here first.

• Input and controls. How the main action feels on every press.
• The first five minutes. Menus, tutorial and the first level.
• Feedback on the core action. Sound, screen shake, particles, small animations.
• Performance on modest hardware. A smooth frame rate reads as quality.
• The store page assets. These are polish too, and they sell the game.

If a feature in the polish pile is not on this list, check that it really scored four yes answers.

Common traps

Three patterns show up again and again in solo projects.

Keeping a feature because it was hard

Time already spent is gone either way. A feature that took a month to build still has to earn its place by the four questions, not by its history.

Polishing what you like, not what players see

It is tempting to polish the system you enjoy coding. Look at what players actually touch most often, and polish that.

Cutting the wrong half

Some features look optional but hold the loop together. If cutting something makes the core action feel pointless, it was core all along. Put it back.

What we would do

We would run the four-question test every two weeks, not once. Scope grows quietly, and a regular sort keeps it honest.

We would also make every cut visible in a short list called "Not in 1.0". Writing cuts down makes them feel like decisions rather than losses, and the list becomes your first update plan.

Finally, we would show the sorted list to one other developer you trust. They will spot the feature you are protecting for sentimental reasons.

The short version

• Test each feature on four questions: core loop, first hour, nearly done, sells the game.
• Four yes answers means polish, three means keep, two means simplify, fewer means cut.
• The simplify pile usually saves the most time.
• Switch features off with flags, play without them, then delete properly.
• Spend polish on controls, the first five minutes and core feedback.

If your scope has outgrown your calendar and you want a hand on the part that is dragging, drop us a line.

Related reading: Solo Dev Scope: How to Finish the Game You Started, What Two Failed Games Teach About Picking Scope, What Goes in Version 1 of Your Game, and What to Cut