Why 90% of Indie Games Die in the Idea Phase

Your indie game isn't stalled because you lack talent, discipline, or ideas. It's stalled because you're doing creative work in an environment rigged to kill creative work.

You probably disagree with that. Most stuck starters do. The first reflex, when a project dies, is to look inward: I didn't have the willpower. I lost the spark. I'm just not a finisher. That reflex is wrong, and it's the single most expensive lie a game developer can believe about themselves. The seven patterns below look like character flaws. They aren't. They're the predictable output of a specific environment, the one every solo indie dev wakes up in by default. Fix the environment, and most of them dissolve.

1. You're building a AAA game with an indie team

The most common killer. You sketched an open-world RPG with branching dialogue, crafting, weather, 40 hours of content. It's going to be incredible. It's also going to take 200 people and five years.

Cyberpunk 2077 shipped with roughly 500 developers behind it. Elden Ring and Armored Core 6 were made by a FromSoftware team of roughly 300. Those are the games you're pattern-matching against when you sketch your first project. Those are the games that got finished and shown to you. Every unfinished game, by definition, you never saw. So your mental model of "what a game looks like" is trained exclusively on the output of armies.

Then you sit down at your desk at 9pm after work, alone, and wonder why the thing you're building feels impossibly far away.

One indie dev puts it bluntly:

"Indie games are often defined by their scope. And that's because a game that's too ambitious either never gets finished or it takes far too long."

The advice "make smaller games" has been repeated so often it's meaningless. Most devs hear smaller and think shorter, so they build a shorter open-world RPG instead of a full one. Still a disaster. Smaller doesn't mean shorter. It means fewer moving parts, each done better.

Mini Metro came out of a game jam with hard constraints: no animated characters, no bespoke levels. It sold millions. The constraints weren't limits. They were design decisions that made the game better and the developer's life easier at the same time. When a decision only does one, it's the wrong one.

The fix isn't willpower. It's a second pair of eyes calling your scope before you've fallen in love with it.

2. Perfectionism isn't a character flaw. It's what happens when nobody's looking

There's a specific moment every solo dev knows. You spend an hour tweaking a variable, nudging a jump arc by a pixel, testing fifteen shades of UI blue. Then you undo everything and go back to where you started. Not quality. Procrastination with a craftsman's apron on.

The part nobody talks about: that behavior is environmental. It only happens when no one else is looking at your work. The second someone is waiting on your build by Friday, the "is this shade of blue exactly right" question stops mattering and the "is the button wired up" question takes over. Playtesters don't care about your jump arc; they care whether the level is fun. Perfectionism thrives in silence.

A veteran indie said it this way:

"A lot of artists aim to create, they don't aim to ship."

The distinction sounds subtle but changes everything. When shipping is the goal, every decision runs through "does this get the game into players' hands?" Instead of perfecting one system for months, you build the whole game to good-enough and save the polish pass for after it's playable end-to-end. Another dev keeps a sticky note above her monitor that just says go with good enough, because she has to remind herself every day.

The sticky note is the point. Left alone, with no external forcing function, your brain will always pick the one comfortable corner of the project and pretend that's productivity.

3. The last 10% is actually 90% of the work (and you thought you were almost done)

You've built the game. The core loop works. Levels are in. Art's in place. You're maybe 90% done.

The brutal truth: you're about halfway there.

The final stretch is an invisible mountain: polish, bug fixing, UI menus, settings screens, five sizes of app store icons, five sizes of splash screens, store listing copy, screenshots, playtesting, balancing, localization, build pipelines. Most projects die here. Not during the fun stuff. Here.

"The last 10% has so many things that you're not even aware of that you have to fix that you have to polish that you have to add."

Indie devs call this the dark work: the labor that produces no visible progress. No new levels, no screenshots to post on Bluesky, no exciting features. Just grinding through the unglamorous stuff that turns a prototype into a product.

One solo dev spent about ten years repeatedly starting projects and quitting each time the dark work started. Not because he was lazy. He was working constantly. Every quit at that stage chipped away at his self-belief as a finisher. By project seven, he'd built a track record in his own head that said "I don't finish things." Self-fulfilling prophecy. He eventually escaped it by publicly committing on camera to shipping one game and refusing to touch anything else until it was out.

The ninety-ninety rule ("the first 90% of the code takes 90% of the time, and the last 10% takes the other 90%") was coined at Bell Labs in the 1980s and quoted in Communications of the ACM in 1985. Forty years later, it's still true. Games aren't exempt. If anything, the dark work in games is worse, because "done" is subjective in a way code behavior isn't.

The failure isn't your stamina. It's that nobody warned you the shape of the work was going to change, and when the change hits, you interpret the slowdown as "I lost motivation" instead of "the job just got harder." Different story, different fix.

4. You're lying to yourself about scope, and nobody's calling you on it

Overscoping isn't a planning failure. It's what happens when the only person evaluating the plan is the person who wrote the plan.

When you pour months into a project, you develop an investment in it that corrupts your ability to read it clearly. You want the scope to be reasonable. You want the niche to be big enough. And when you want something to be true badly enough, your brain filters out the evidence that says otherwise.

"Why do people spend four years on projects? They want to believe that they're going to be successful, they want to believe they're going to sell a million copies."

Tom Francis, the developer behind Gunpoint and Heat Signature, wrote publicly that Heat Signature took roughly two years longer than planned. The core idea couldn't be validated in small prototypes, and he didn't catch it early enough. He's a good developer. He's done it before. He still got caught. The difference between him and the solo dev whose scope eats them alive isn't talent or self-awareness. It's that Tom talks about it afterwards, in public, so the rest of us can learn. Most overrun projects just quietly die, and the lesson dies with them.

The uncomfortable part: the bias against seeing your own scope clearly is almost unfixable from the inside. You cannot evaluate a project objectively when your identity is tied to it. The fix has to come from outside: playtesters, a partner, a mentor, someone who isn't emotionally invested and will tell you the niche is too small or the content pipeline is too long before you've burned eighteen months on it.

Solo devs don't fail at scope because they're bad planners. They fail because there's no one in the room to say "are you sure?"

5. Shiny object syndrome is a dopamine problem, not a discipline problem

Starting a project is a drug. Everything's exciting. The possibilities are infinite. Your brain is firing because you're in the creative honeymoon phase.

Finishing is the opposite. The scope is locked. The problems are known. The dopamine of novelty is gone, replaced by the grind of fixing the same animation bug for the fourth time.

Some devs spend 90% of their gamedev time in that cycle: start, get excited, hit the first wall, pivot. One of them described the aftermath this way:

"Zombie projects — the projects that we don't officially quit but we move on to other projects, technically still working on them but we haven't really touched them in a few months."

The zombie projects are the worst part. Each one hangs around in the back of your mind as a guilt-inducing open loop. You haven't officially quit them, so they drain mental energy without producing anything. Your attention is technically still allocated to eleven games, even though you're only working on one. No wonder you feel exhausted.

This isn't laziness either. It's what a novelty-seeking brain does when there's no external cost to walking away. Nobody else has shipped assets into your repo. Nobody is blocked on your Friday build. You can ghost a project at zero cost, so your brain ghosts every project the moment the dopamine runs out. The cost isn't zero. It's the graveyard. But the cost is paid years later, not today. Your brain discounts it to nothing.

The fix is twofold. First, quit your zombie projects on purpose. Say out loud: this is dead, it's okay, I can let it go. Closing the loop is worth more than trying to silently maintain it. Second, if you can only stay excited about a project for four weeks, don't plan a six-month game. Plan a two-week game, because it will take a month.

Or attach a cost to walking away. Put someone on the other end who's counting on your work by Friday. The cost of abandoning stops being zero. Your brain recalculates. Suddenly the novelty of a new project gets weighed against the real cost of leaving a teammate hanging, and for most people that math breaks in favor of finishing.

6. There's no finish line, and perpetual development is safer than shipping

Software has a natural "done": the tool does what it was built to do. Games don't. There's always another feature, another system, another layer of content. No alert pops up saying "game finished, 100%." It never happens.

"Games are never really finished, they're just good enough to be launched. If you don't stay focused it's really easy to turn a three-month game or a weekend game into three years."

Which means finishing is an active decision, not a natural endpoint. You have to decide it's done, even when it doesn't feel done. And that decision terrifies people, because shipping means facing marketing, reviews, the Steam algorithm, and the possibility that players won't like what you've made.

Hiding in perpetual development is safe. Nobody can criticize a game that hasn't launched. "It's not ready yet" becomes a shield, and the shield feels like craftsmanship but functions like avoidance. The solo dev behind Blue Prince worked 80 hours a week for eight years straight to finish his roguelike and said afterwards he "physically cannot make another game this ambitious." That's what shipping at the end of an eight-year perpetual-development cycle looks like. Not romantic. Survival.

One solo dev on Hacker News put it this way:

"The biggest problem with building solo is you have nobody to balance out your down periods. If you're not being productive then everything is stalled."

When you're a one-man army on a game, every bad week is a project-wide stall. There's nobody picking up slack, nobody losing anything when you don't ship, nobody to nudge you into the uncomfortable "okay, this is done" call. Perpetual development isn't a personality. It's the default outcome of a team of one.

7. The one you can't see: "I can't do that" kills more projects than any bug

This one is quieter than the others, and probably the deadliest.

It's the split-second shutdown when your brain says "you can't do that" and an entire possible future for your game vanishes. Procedural generation? You're not smart enough. A unique art style? You're not talented enough. Networking? You're not experienced enough. The project dies before a line of code is written. You don't even notice it die. It just wasn't there one thought later.

"The biggest handicap that I see game developers have is the fact that they think they have a handicap."

The brutal irony is that the tools and tutorials available to a self-taught developer today would have been science fiction twenty years ago. The barrier to making games has never been lower. You're almost certainly capable of most of the things your brain is telling you you can't do. You just don't want to do them, or don't want to do them alone, which are different conversations.

A small linguistic shift helps. Instead of "Can I do this?", which invites a yes-or-no verdict (usually no), ask "How would I do this?" The second question forces your brain into solution mode. You don't need the answer right away. You just need to keep the door open long enough to walk through it. And having someone next to you who says "yeah, you can do this, here's where to start" is worth ten self-help books.

"But what about the solo devs who do ship?"

Fair. They exist. Stardew Valley. Undertale. Axiom Verge. Blue Prince. Real games shipped by one person. If the problem were purely structural, they shouldn't exist. So what gives?

Look closer at any of them and you find the same thing: every successful solo dev manufactured the structure that teams get for free. ConcernedApe spent years posting regular devlog updates, which functioned as an external deadline and a playtester feedback loop. Toby Fox had a fanbase pulling updates out of him. Most of them had a partner or family member watching the scope and calling it out when it drifted. Blue Prince's dev worked in near-total isolation and paid for it: eight years, broken body, "I can't do this again."

The pattern isn't "solo devs ship and team devs don't." The pattern is "the solo devs who ship have built the scaffolding of a team around themselves by other means, and the ones who don't build that scaffolding don't ship." That's still a structural story. It just has one more DIY step.

Which is fine if you have the energy and self-awareness to be both the builder and the scaffolding. Most people don't. Most people try, burn out, and end up with another entry in the graveyard. The "cursed to work alone" framing you see in solo-dev threads isn't poetic. It's diagnostic.

What this actually means for you

Pull the frame back for a second.

Every pattern above looks like a personal failing from the inside. Lack of discipline. Perfectionism. Lost motivation. Fear of shipping. Self-doubt. But they all have the same environmental cause: you're doing the work in isolation, with no external forcing function, no one to balance your down weeks, no one catching your scope before you fall in love with it, no deadline you can't quietly renegotiate with yourself.

The fix isn't more grit. It's the four things successful finishers put around themselves, whether they're solo or on a team:

1. Someone counting on your work by Friday. A real person, not a to-do list. The psychological math is entirely different when a teammate is blocked on your build.
2. An external deadline you can't renegotiate alone. A jam submission, a demo day, a publisher milestone, a co-founder's calendar. Something you can't quietly push to "next week" forever.
3. Playtesters who don't love you. The feedback your partner gives is nice. The feedback a stranger gives is useful. You need the second kind early and often.
4. A second pair of eyes on your scope. Before you've burned six months. Before you've fallen in love with the idea. Someone who can say "are you sure this is shippable?" without you taking it as a personal attack.

You can build all four of these alone. Some people do. It takes an enormous amount of self-management on top of the game itself, which is why most solo attempts stall out. You're trying to be both the builder and the scaffolding.

Or you can build them on purpose, with other people.

That's why we built Clowdr. Not another dead Discord project. A team: structured accountability, a shared playbook, someone actually expecting your Friday build. Contributors keep the rights to their work. Deadlines are real. Scope gets called out before it eats you. It's one way to get the structure on purpose instead of hoping you stumble into it.

If you're tired of watching your projects die in the idea phase, the answer is almost never "try harder alone." It's finding the people who'll make trying harder redundant.

Related reading: Scope Creep Is Killing Your Game walks through the scoping trap in detail, Solo Dev vs. Team gets into the false binary head-on, The Complete Guide to Finishing Your Indie Game is the playbook version of this post, and How to Find Reliable Teammates for Your Indie Game Project gets into the "who" question once you've decided on the "how."

The projects dying in your graveyard aren't evidence of who you are. They're evidence of what you've been doing the work inside of. Change the container. The rest follows.