Most indie prototypes get judged the same way: "what's in it?" Feature list, mechanics implemented, levels playable. It's the wrong number.
Adding features is easy. Three weeks and a stubborn engineer can add almost anything. What's hard — and what predicts whether a game ships — is figuring out what to remove before any of it costs real time.
What to measure instead
Two numbers, neither of them about the feature list:
- Cuts per week. From scope, from the doc, from the build. How many ideas did the team retire this week with conviction? If the answer is zero, the prototype isn't a prototype yet — it's a vision board.
- Time to first "no." From design pitch to the first time a teammate says "we shouldn't build this" and the team agrees. The shorter that loop, the cheaper the cuts get.
These numbers are unflattering. That's the point.
The trap
Teams measure features because features are easy to demo. Cuts are messier — they require someone to lose, and they only feel right in retrospect. "We cut the crafting system" plays badly in a publisher meeting; "we cut the crafting system and the rest of the game tightened by 40%" plays brilliantly six months later.
The prototypes we've shipped that worked weren't the most featured. They were the ones where, by the end of the prototype phase, the scope doc was shorter than when we started.
That's the bar.