clowdr.devIndie Game Postmortems: 7 Reasons Projects Die After Year One
Indie game postmortem analysis: 7 reasons projects die after year one - scope, burnout, team collapse - and the structural fix each one needs.
You can find a thousand posts about why 90% of indie games die in the idea phase. Almost nobody writes about the graveyard that opens up between month fourteen and month twenty-eight, where actual shipped games and shipped studios go to die.
This post walks that graveyard.
We read through more than a dozen public postmortems, the IGDA's 2023 Developer Satisfaction Survey, the GDC Failure Workshop talks, Game Developer magazine's cancellation write-ups, and the louder indie dev YouTube channels that cover their own collapses. Seven patterns kept showing up. None of them are "lack of willpower." They cluster in the exact spots where a second chair would have been sitting.
"There's so many great games and art projects and beautiful things that we'll never get to see because somebody thought intensity was the right answer and they worked intensely and then they burned out and never touched it again." - Tim Ruswick
You're not lazy. You're unsupported. The postmortem record makes that sentence concrete.
If you're looking at your own project thinking "something's starting to slip," the odds are good that one of the next seven is why. Each section names the structural cause, not the character flaw, and names a team-decision that would have caught it. We wrote a longer version of how a few of these interlock in the 90-90 rule of indie game dev; the middle of this list is where that rule starts biting.
1. Scope metastasized past the calendar
The public postmortem version of this: "we overscoped." The felt version: every month, the design document grew a little, the calendar did not.
Tim Ruswick spent ten years finishing his first game. His own diagnosis wasn't lack of skill. It was "I would start a project, I would build it out, I would learn so much that I'd be like oh my god this is a giant mess, and then I would start over." Each rewrite imported last round's scope plus a new round of "while we're in there." Game Developer magazine's recurring line on the indie iceberg: "overambitious scoping is a classic indie failing." Reddit's version: "A 4-year game is absolutely massive and sounds like it's overscoped."
None of those people were lazy. Ruswick was shipping hours. The Reddit poster was working on a four-year game. Who does that without commitment? What they were missing was someone with authority to close the scope.
Solo devs cannot close their own scope. The version you're building lives in your head, and the urge to polish it is indistinguishable from the urge to make it good. Every "one more feature" argument gets both sides delivered by the same voice.
The team-decision fix is a named scope-owner who is not you. On a collaborative indie team, this is the person with permission to say "feature rejected, we're past the cutoff." For a longer walkthrough of how scope specifically keeps eating your schedule, see scope creep is killing your game.
2. Nobody checked the core until it was too expensive to fix
The StarLicker team took their prototype to IndieCade judges. The feedback was a clean sentence: "You nailed everything but the core gameplay." They mostly dismissed it. Post-launch, 65% of matches ended in forfeit. Their own public postmortem calls out time and money pressure as the reason they didn't re-architect the core earlier.
Dryden, who made Disinherited, spent nearly a full year on his Metroidvania before showing anyone. First external playtest exposed that the opening was too long, too hard, and never introduced the game's mechanics. That's the kind of note you can only act on at month three. By month eleven, the rewrite cost is structural. By month twenty, it's terminal.
Here's the pattern: solo devs rarely ship with broken cores. They ship with unvalidated cores. They think they're polishing. They're hiding from the one test that would have saved the project.
The team-decision fix is a vertical slice gate. You don't earn the right to make content until a second party has played the core loop and said "yes, this earns scaling." Our full walkthrough of the finishing problem, including where the vertical-slice gate sits in the timeline, is in the complete guide to finishing your indie game.
3. The team quietly dissolved in month six
There is no Discord announcement. Eric Nevala's oft-quoted line from "Your Indie Game Dev Team Will Fail" captures the pattern: "Eventually, real life wins more frequently, and the total amount of weekly commitment by contributed hours dwindles off... Many people just lose interest and silently fade away... Gradually, a few members just disappear entirely for one reason or another."
This is the most common team-collapse pattern in indie. Nobody rage-quits. There's no breakup. A message goes unanswered for four days, then six, then two weeks. Your producer assumes they're busy. They assume you're busy. Two months later you realize you haven't heard from them since March.
The cause is structural, not about character. Volunteer teams without committed contributor agreements decay at a predictable rate, the way anything does when the cost of leaving is zero. The project becomes the last thing anyone reschedules when their day job gets loud.
The team-decision fix is a structured commitment: a signed contributor agreement that names deliverables, plus a weekly demo someone is counting on. Add even a small cost to silently fading. Nevala's own advice: "Assume everyone else on the team is going to eventually quit or ghost the project." If that sounds grim, see how to find reliable teammates for your indie game for the inversion: filtering in before anyone signs up.
4. Year-one burnout arrived exactly on schedule
IGDA's 2023 Developer Satisfaction Survey: 40% of indie developers reported burnout that year. 55% of indie teams experienced crunch. These are not edge cases. This is the expected condition of indie development.
Ruswick describes the mechanism: "The more intense you go, the longer you're intense, the more burnout you get on the other end, the less you feel motivated, the more you don't want to look at your project ever again... there have been months of my life where I don't even want to sit down at my computer like that's how hard I went."
The project doesn't die because you gave up. It dies because your body stops letting you open the engine.
"I don't necessarily agree with a culture that valorizes people working themselves to death in their spare time to make a game that is far too ambitious." - IndieGameClinic
Read the verbatim comments and the language gets darker. "You can fix your mental health later, now torture yourself and finish it because it looks crazy good" is a real Reddit reply. "If you've been torturing yourself over a project - just drop it. You're destroying yourself mentally, and you simply can't waste time doing that" is how one dev announced cancelling a three-year project and called it the happiest he'd been in years.
The team-decision fix is load distribution: a teammate who notices when you stop showing up, Sundays you don't have to defend, and the ability to hand the next sprint off to someone else for a week without the project dying. Solo devs cannot do any of this by themselves. That is what solo means.
5. The pivot you knew was coming never came
Matt Gilgenbach's GDC postmortem on Retro/Grade is unusually honest about this. He describes knowing, for months, that his OCD was making the game larger and larger, unable to authorize himself to cut the scope he'd committed to. Joe Mirabello's Failure Workshop talk after Tower of Guns covers the same ground: the dev knows the game isn't working, and cannot fire themselves from the direction they chose.
This is the "one year in, we should have killed this" entry in almost every postmortem you read. The knowledge was there. The decision wasn't.
Solo devs cannot pivot alone reliably. Pivoting requires somebody to accept the sunk cost you just cashed in. If the money and the calendar and the reputation are all yours, the argument against the pivot is also yours. Every voice in the room is you. "If I quit now, three years were for nothing" is the most common Reddit phrase in this category, and no solo dev ever talks themselves out of it.
The team-decision fix is a scheduled kill-or-continue review. Every quarter (or milestone), the team asks one question with a written answer: "Would we start this project today, knowing what we know now?" If the answer is no, the team has explicit authority to recommend shutdown or a full rebuild. Someone besides you has to be able to say "it's okay to stop." See solo dev vs team for how this decision authority gets structured.
6. The launch was into empty air
Jonathan Powell's "How I Failed as an Indie Dev" is unflinching. Thirteen months, twenty thousand dollars of his own money, a polished first indie. Paid release: sales dropped to zero within days. A later free release of the same game: 12,000+ downloads.
The game worked. The audience didn't exist.
Every SERP competitor on "why indie games fail" lists marketing as a top-three cause. Five out of the five highest-ranked pages we audited list it. The framing they share is "the dev didn't market enough." That's backwards. A single person cannot build a six-month audience and ship a polished game inside the same calendar. These are two jobs.
"No marketing" is a staffing problem, not a discipline problem.
The team-decision fix is a marketing contributor brought in at month minus-six, not month plus-zero. A community-builder, a press contact, a person whose job is to have written two thousand people onto your Steam wishlist by the week you hit "release." That is what "brought in early, not brought in last" means in Clowdr's collaboration pillar. Your composer, your artist, and your marketer are vendors if you bring them in at 90% done. They are partners if you bring them in at 10%.
7. Post-ship grief quietly closed the studio
Joe Mirabello shipped Tower of Guns and still felt like a failure. He gave a talk about it. Spry Fox's founders, after their Netflix deal ended, cut their own salaries to twenty thousand dollars a year so the studio could keep existing. One indie dev's farewell essay: "I'm tired of making games, so I'm leaving GameDev. I don't know when I'll be back. And is it worth it?"
Shipping the game does not save the studio. The come-down after launch, combined with the financial pressure that launch rarely relieves, closes the door on the next project. What kills year two is year one's grief, not year one's scope.
As one Game Developer piece put it, a single bad release can bankrupt an indie, because two years of labor is a couple hundred thousand dollars in unpaid wages. The launch doesn't reset that clock. It exposes it. Solo devs discover at month 25 that they have to get a job again, and the next project never starts.
The team-decision fix here is the hardest one to write about honestly. The team has to survive the launch. Solo studios rarely survive one. Two-person studios sometimes survive two. Teams make better games (they do), but the more important thing they do is distribute the grief of shipping so no one person carries it alone.
If you've been reading this and thinking "year one is the cliff," the postmortem record disagrees. Year one is really year zero for the next game. See why 90% of indie games die in the idea phase for what that means on the front end.
Which of the seven is already creeping into your year two?
Seven patterns. Six of them have a team-decision fix the solo dev cannot execute alone. The seventh, post-ship grief, has a fix that requires having a team to begin with.
That ratio is the point of this post. The postmortem literature does not read like seven different problems. It reads like one problem, structural isolation, showing up in seven different months of the project.
"You're not lazy. You're unsupported" is the most consistent finding in the indie postmortem record. It is not a pep talk.
If you're staring at a project that's starting to fit one of these patterns, the honest question is not "how do I push harder." It is "who is the second chair this project needs, and how do I get them in it?"
Clowdr is built around that second chair. Managed indie game teams, structured commitments, retained IP, someone counting on your work by Friday. If any of the seven looked familiar, sign up for Clowdr and we'll help you find teammates who ship.