The case for shipping small games

Every dev I know has a graveyard. Mine is full of ambitious games that got 40 percent built and then died quietly when the scope outran the weekend energy. The thing that changed my output was deciding to ship small games on purpose, and to call a two-week thing finished even when part of me wanted it to be a year-long thing. That decision did more for my skills than any tutorial.

Why shipping small games beats hoarding a big one

A big project hides its problems. You can spend months on systems that feel productive (an inventory framework, a save system, a fancy dialogue tree) and never once put the game in front of a human who decides in three seconds whether it is fun. A small game forces that moment early. You finish, you hand it to someone, and you learn the truth fast.

There is also a compounding effect. If I ship six tiny games in a year, I have crossed the finish line six times. Crossing the finish line is its own skill, separate from building things. It involves cutting, polishing, packaging, and letting go. The person who shipped six small games is better at all of that than the person still grinding on the one masterpiece.

Finishing is a muscle, not a personality trait

I used to think some people were just finishers and I was not one of them. That is wrong. Finishing is trained. The first few times you push a game out the door it feels terrible, because you can see every seam. By the tenth time you have a calmer relationship with imperfection. You know which seams matter to a player and which ones only you will ever notice.

The same muscle carries into regular software work. Plenty of engineering careers stall not on hard problems but on the last 20 percent, the unglamorous part where you wire up errors, write the readme, and ship. Game jams trained that out of me harder than any job did, because a jam has a literal clock and at the end you either submitted or you did not.

What small actually means

Small is not a word, it is a constraint you write down before you start. For me a small game has one core verb, one win condition, and roughly one screen of mechanics you could explain to a friend at a bar. If I cannot explain it in two sentences, it is not small, it is a medium game wearing a small costume.

Here is the test I run before committing a weekend to something:

• Can I name the single thing the player does over and over, the core loop, in one short phrase
• Could a stranger understand the goal in the first ten seconds without a tutorial
• If I deleted half the features I am imagining, would the core loop still be fun
• Can I get a playable, ugly version running by the end of day one

If any of those is a no, I cut until they are all yes. The cutting feels like loss in the moment and like relief by the end.

The hidden technical payoff

Small games let you actually try things. I have used tiny projects to learn a new engine, to test how an ECS feels in practice, to prototype a netcode idea, to mess with shaders I would never risk on a serious build. Because the stakes are low, I experiment more aggressively, and aggressive experimentation is where the real learning lives.

They also keep your architecture honest. A two-week game cannot afford five layers of abstraction. You write the direct thing, you feel where it hurts, and you carry that intuition back into bigger systems. A lot of overengineering in production code comes from people who never built anything small enough to feel the cost of their cleverness.

How I keep the scope honest

My main trick is a hard deadline that I treat as real. A jam gives you one for free. Outside a jam I invent one and tell at least one other person, because saying it out loud makes it harder to quietly slip. When the deadline is near and the game is not done, I do not extend the deadline. I cut the game. That order matters and it is the whole discipline in one sentence.

The other trick is shipping the ugly version first, then polishing only if there is time left. A blocky cube that moves and wins is a finished game. The same cube with juice, sound, and a title screen is a better finished game. But the order is non-negotiable, because polish on top of an unfinished core is just procrastination with nicer textures.

What you get on the other side

After enough small games you stop fearing the blank project folder. You know roughly how long a thing takes, you know your own pace on a Saturday, and you trust yourself to land it. That confidence leaks into everything else you build. The big ambitious game, if you still want it, becomes possible precisely because you spent a year learning to finish on the small ones first.

My advice is plain. Pick something you could finish this week. Write down what done means before you write a line of code. Then ship it, flaws and all, and start the next one. The graveyard shrinks and the skill grows.