Studio Notes · July 6, 2026

Writing a Postmortem After Shipping Your First Shmup

The postmortems that actually get read and actually get useful comments are the ones that admit what went wrong in specific, checkable detail — not the ones that list three positives, three negatives, and close with a vague note about how proud the team is.

Published July 6, 2026

A postmortem written a week after launch, while the sales numbers are still moving and the reviews are still coming in, tends to be either too defensive or too self-critical, because the emotional distance needed for a level-headed account hasn't arrived yet. Waiting four to eight weeks gives enough time for the initial launch adrenaline to fade and enough data to actually see the shape of what happened — wishlist conversion, review sentiment settling into its real average, and refund patterns that only become clear once the first rush of players has moved through the game.

Anchor claims to numbers you actually have

"Marketing didn't work" is not a useful sentence in a postmortem. "Wishlists grew by roughly forty a week during the eight-month pre-launch period, spiked to several hundred in the week of the festival demo, and returned to baseline within ten days" is useful, because it's checkable and it tells the next project's marketing plan something concrete about which specific activity actually moved the needle. If your team didn't track wishlist counts, review sentiment, or traffic sources during development, that absence is itself worth writing down as a lesson, because the fix for the next project is simply to start tracking from day one rather than trying to reconstruct history after the fact.

Separate "we didn't know" from "we knew and didn't act"

These are different failure modes and they need different fixes. A scope problem the team genuinely couldn't have predicted — a critical middleware library getting deprecated mid-project, say — points toward better contingency buffers next time. A scope problem the team saw coming for months and kept deferring because addressing it felt disruptive points toward a process failure: something about how the team surfaces and acts on known risks needs to change, and no amount of extra schedule buffer fixes that on its own. Conflating the two in a writeup makes both harder to actually learn from.

Cover technical decisions with the same honesty as business ones

It's common for postmortems to dwell entirely on marketing and business outcomes and skip technical retrospection almost entirely, which is a missed opportunity for a small team where the same people making business decisions are also the ones who'll be writing code on the next project. If the engine choice covered in choosing a game engine for a 2D shmup turned out to be a poor fit for the team's actual workflow, or if the object pooling architecture from object pooling for bullets had to be substantially reworked mid-project because it was designed before the bullet density requirements were understood, those are exactly the kind of specific, actionable technical lessons that make a postmortem worth writing at all.

Decide who the postmortem is actually for

A postmortem meant purely as an internal team document can be far more blunt and specific than one intended for public release, and trying to write one document that serves both purposes usually means it serves neither well — the internal-honesty parts get softened for public consumption, and the public-facing marketing value gets diluted by internal process detail nobody outside the team cares about. Many small studios write two versions: a candid internal document with real numbers and named mistakes, and a shorter public version that shares the interesting lessons without airing every internal disagreement. Deciding this upfront, before writing either one, saves a lot of painful editing later.

The next project's plan should visibly reference this one's lessons

A postmortem that gets written, published, and then never referenced again during the next project's planning phase has only delivered half its value. The real payoff comes from deliberately pulling specific lessons forward — if the previous postmortem identified that scope crept because milestones weren't reviewed often enough, the next project's plan should include a concrete, named checkpoint cadence rather than a vague intention to "manage scope better." Teams that keep a running document of lessons across multiple shipped projects, revisited explicitly at the start of planning for each new one, tend to see the same categories of mistake shrink release over release; teams that write a postmortem purely as a closing ritual for the previous project tend to relearn the same lessons from scratch each time.

Whichever version gets published, the value of the exercise comes almost entirely from specificity. A postmortem that could have been written about any indie game, with the nouns swapped out, wasn't worth the time it took to write.