Why We Prototype Ugly and Fast
Why we test whether a game idea is fun using ugly, throwaway prototypes — and how rapid prototyping saves a small studio months of building the wrong thing.
The most expensive thing a small studio can build is a beautiful version of a game that was never fun in the first place. Gorgeous art, a slick interface, a soundtrack someone laboured over for weeks — all wrapped around a core that nobody actually enjoys playing. By the time you realise, you have already spent months polishing a corpse.
So before we make anything look good at Little Gary Games, we try to settle a much harder question first: is this fun, or should it die? Everything else waits behind that answer.
What does “finding the fun” actually mean?
Every game has a verb at its heart — the single thing you do, over and over, that you would happily keep doing even if nothing else were bolted on. Jumping. Stacking. Aiming. Routing units across a grid. Finding the fun means isolating that verb and asking one blunt question: is this, on its own, enjoyable?
If the core verb is dull, no amount of story, art or progression will rescue it. If the core verb sings, almost everything else becomes a way to give players more of it. That is the whole reason we hunt for the fun before we commit to anything around it — the verb is the foundation, and you cannot retrofit a foundation once the house is built on top.
Why ugly prototypes win
Our first prototypes are deliberately ugly — grey boxes, placeholder shapes, programmer art that nobody could love. There are two reasons we keep them that way.
• Speed. An ugly prototype takes hours, not weeks. We can test five ideas in the time a polished version of one would cost us, which means we find out faster which ideas are worth keeping.
• Emotional honesty. It is very hard to cancel something you have made beautiful. The moment a prototype looks good, you start defending it instead of interrogating it. Ugly keeps it disposable, and disposable is exactly what an early idea needs to be.
Can you prototype on paper?
Often, yes — and it is the fastest tool we have. For anything turn-based or systems-driven, a board, some tokens and a handful of index cards can answer the fun question before a single line of code exists. You can change a rule mid-game just by saying it out loud. You can rebalance the whole thing with a marker pen.
Paper will not tell you how something feels in real time — reflexes, timing and game feel need a build. But it will tell you whether the decisions are interesting, and interesting decisions are the part most likely to be broken. We reach for paper first and move to code only once the underlying idea has earned it.
How long should a prototype live?
Not long. We timebox a prototype to a few days and agree the kill rule before we start — something like “if it isn’t fun by Thursday, it’s done.” Setting that rule up front matters, because in the moment everyone is far too close to the work to judge it fairly.
A prototype’s job is not to survive. Its job is to answer a question. The moment it has answered — yes this is fun, or no it really isn’t — it has succeeded, even when the answer is no. A prototype that gets cancelled on schedule is a prototype that did exactly what it was for.
What do we keep from a prototype?
Almost never the code. The throwaway build is genuinely thrown away, and we have learned not to mourn it. Reusing prototype code is how a quick experiment quietly becomes the unmaintainable backbone of a real project.
What we keep is the feeling: the exact moment a tester leaned in, or laughed, or said “let me try that again.” That moment is the seed. Everything we build afterwards — properly, with real art and real systems — exists to protect and amplify it.
Why this matters more for a small team
When you have a hundred people and a long runway, you can afford to be wrong for a while. We can’t. Every month spent building the wrong thing is a month we don’t get back, so the discipline of proving the fun early isn’t a nice-to-have for us — it’s survival. It keeps our arguments grounded in evidence rather than taste, and it keeps us attached to questions instead of features.
Build ugly, build fast, and find the fun before you fall in love. It is the cheapest insurance a small studio can buy. We write more about how we work in the rest of these design notes — if you care about the craft side of games as much as we do, the series is for you.