How We Plan 30 Games: The Spreadsheet That Kept Us on Track

Planning 30 games simultaneously is a logistics challenge. We used a single spreadsheet to track everything: concept viability, development status, page content, technical specs, and deployment state. Here's the system we built.

The 3-Pass Pipeline

Each game passes through three stages: Concept (idea, mechanics, feasibility score), Code (prototype, polish, testing), and Content (wrapper page, strategy article, metadata). At any given time we have games in all three stages.

The key insight: content creation takes longer than coding for most games. Writing a 1,000-word strategy guide with personal anecdotes takes 2-3 hours. Building the game itself takes 1-4 hours depending on complexity. We found that starting content while coding was in progress kept both workflows efficient.

What Got Cut and Why

Of the 45 game concepts we considered, 15 made it to production. The other 30 were cut at various stages. Some were cut for technical reasons (required WebGL shaders that didn't work on budget phones). Some were cut for content reasons (the gameplay loop wasn't satisfying after 30 seconds). And some were cut for market reasons (too similar to existing games in our catalog).

One specific concept that was painful to cut: a 2D platformer with procedural level generation. The technology worked — the algorithm generated interesting levels reliably. The problem was that the generated levels, while technically varied, all felt the same. The player couldn't tell the difference between level 5 and level 50. Manual level design creates intentional variety that procedural generation cannot replicate without AI-level sophistication. We decided that a game with repetitive levels was worse than no game at all, so we shelved it.

Another concept that made it far but ultimately failed: a rhythm game using Web Audio API to generate music procedurally. The music generation was impressive — it produced listenable, structured songs with bass, melody, and percussion. But the latency between user input and audio feedback on Bluetooth headphones (200-400ms) made the rhythmic accuracy impossible to calibrate. We could have forced wired headphones, but that's not a good user experience for browser games played on the couch. So it got cut.

The Columns That Actually Mattered

Our planning spreadsheet went through several versions before we found the columns that earned their place. The ones we kept: a one-line core mechanic, an estimated build time, a "fun risk" rating from one to five, and a dependency note. The columns we deleted were the ones that felt productive but never changed a decision — elaborate priority scores, detailed feature lists, projected play counts. A planning artifact is only useful if it changes what you do next; columns that look organized but never alter a decision are just decoration.

The Fun-Risk Rating

The most valuable column turned out to be the subjective "fun risk" rating — our honest guess about whether a concept would actually be fun once built. Games with high fun-risk got a quick throwaway prototype before any real work, because the spreadsheet flagged them as gambles. This saved us from fully building several concepts that looked great on paper and felt flat in practice. A number that captures gut uncertainty, used to trigger cheap experiments, prevented more wasted weeks than any precise estimate ever did.

Why We Stopped at Thirty Rows

A planning document that lists two hundred game ideas is a wish list, not a plan. We deliberately capped the active spreadsheet at the games we genuinely intended to build in the near term, and kept a separate, ignored "someday" list for everything else. Mixing aspirational ideas with committed work makes the committed work feel optional and the aspirational work feel obligatory. Keeping the real plan small and the dream list out of sight kept us shipping instead of endlessly re-prioritizing.