clowdr.devHow to Finish Your Indie Game: The Complete Guide
Finishing is structural, not willpower. The complete guide on how to finish indie game projects: scope, perfectionism, the last 10%, and when to ship.
Finishing an indie game is a structural problem, not a willpower problem. Most devs quit because they're doing it alone, not because they're lazy or unskilled. This guide names the patterns that kill projects, and the structural fixes that actually ship them.
Table of contents
- Finishing is structural, not moral
- Scope for the person you actually are
- Build a skateboard, then a bike
- Keep the game playable on every workday
- Perfectionism is what isolation rewards
- Kill your zombie projects
- The urge to restart is the discomfort of progress
- Consistency beats inspiration
- Set a real deadline (and tell someone)
- The last 10% is the 90% nobody warned you about
- Finishing is a decision, not a state
- Questions indie devs ask about finishing
- You don't have to finish alone
Finishing is structural, not moral
If you can't seem to finish your indie game, the reason probably isn't discipline or talent. It's structural. You're trying to do a job that was never designed to be done alone, and most advice telling you to "just be more disciplined" is naming the symptom, not the cause.
Start with the data. An empirical study of 23,485 Steam releases found that 48% of games had delayed launches, with the delay pattern holding steady across genres (Queen's University, 2022; retrieved 2026-04-10). That's counting the games that did ship. Nobody tallies the ones that quietly died in somebody's projects/ folder, because those devs never announced a release date in the first place.
One indie founder writing in Game Developer described "over a dozen projects in five years with zero shipped releases", attributing it to what he called a "magpie mindset": the itch to jump to something new every time the current project started to feel like real work (2023; retrieved 2026-04-10). David Maletz, writing in the same publication, put it more bluntly: "the vast majority of indie game developers fail to finish their game projects". Not a minority. Not an unlucky subset. The majority (retrieved 2026-04-10).
Across hundreds of indie dev journeys we've studied (Reddit threads, postmortems, live build updates, GDC talks), the same pattern shows up. Lone devs hit the same walls in roughly the same weeks. Not because they share a character flaw, but because they share a situation. Nobody's waiting on their work. Nobody's checking in. Nobody's naming the drift when it starts. That's the structural problem. Everything in the rest of this guide is either a pattern that emerges in that vacuum, or a fix that puts some structure back in.
And the "it takes way longer than you think" part has a name too. Tom Cargill at Bell Labs captured it in "the ninety-ninety rule": "The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time" (retrieved 2026-04-10). That's not a joke. That's section 10 of this guide.
If you take one thing from this section: the 90% failure rate isn't a failure of individual devs. It's a failure of the structure around them.
Scope for the person you actually are
Scope your game for who you actually are, not who you plan to be on your best day. "Make smaller games" is the most repeated advice in indie dev and the most useless, because everyone nods and then builds a slightly smaller version of Stardew Valley. Real scope discipline isn't about shorter playtime. It's about cutting entire categories of work.
Every system you add is a system that has to be as good as the equivalent system in the game your players will compare you to. If you make a farming sim, your inventory has to be at least as good as inventory in comparable farming sims. Your dialogue has to hold up. Your NPCs have to schedule. Your crops have to grow. That's not one game's worth of work. That's twelve games' worth of work, and you have to carry every one of them at the same time.
Now imagine a game that removes an entire axis. Downwell is a game about falling and shooting. No horizontal movement. That single constraint eliminated whole categories of design problems, and it let one developer put real polish into every screen. Mini Metro started with two self-imposed rules: no animated characters, no hand-crafted levels. Both rules killed weeks of work before a single line of code was written. Both games shipped. Both made money.
The structural fix: decide what your game won't have before you decide what it will have. "No characters to animate." "No cutscenes." "No tutorial." "Single screen only." "No mouse input." Write the constraints on a sticky note and tape it to your monitor.
Then be honest about your actual attention span. If you know, from past experience, that projects in your life tend to die at week six, you don't get to plan a ten-month game. Plan a four-week game. It'll take six. That's the math.
Scope is where scope creep starts eating your project. The fix begins before you write a single line of code.
Build a skateboard, then a bike
There's a famous product-dev diagram. The wrong way to build a car is to build a wheel, then two wheels, then a chassis, then a body. The right way is to build a skateboard, then a scooter, then a bike, then a motorcycle, then a car. Every stage is something a person can actually use. Your indie game should work the same way.
A lot of devs spend months building systems before they build a game. The procedural generation engine, the save/load architecture, the inventory framework, the dialogue compiler. Brilliant code. Nothing to play. Then one day they look at what they've built, realize nobody can actually experience it yet, and the motivation collapses.
The fix is called a vertical slice: a thin but complete cross-section of your game. Not all the systems with no art. Not all the art with broken systems. A slice where the core loop works, there's some sound, it looks passable, and someone who's never seen it before could sit down and play for two minutes. That's your skateboard. It's not the car. But it moves, and it's real.
Juha Vainio, writing for Game Developer, nailed the framing: "MVP is a mindset, a way to recognise what is important in the game and what is not" (2015; retrieved 2026-04-10). Not a feature list. A way of seeing.
One dev who's shipped a lot of small games put the cost of doing it the other way plainly: "If you're practicing not finishing things, you're getting really good at not finishing things. You see how that works?" Every month you spend in pre-playable mode is a month of building identity as a person who doesn't ship. Build the skateboard in week one. Then expand outward.
How to apply this. Your week-one question isn't "what tech do I need?" It's "can the player do the one thing my game is about?" If the answer isn't yes, you're building in the wrong order.
Keep the game playable on every workday
Every workday should end with the game in a state where a stranger could pick it up and play it. Not polished. Not complete. Just running. When the game stops being demonstrable for weeks at a time, you lose two things at once, and both of them kill projects.
The first thing you lose is feedback. A game that can't be played can't be tested, which means you drift. You can spend a month building the "better" version of a system that was fine, because there was nobody around to say "actually the old one was good." The second thing you lose is the psychological fuel of watching your game be a game. Staring at code files is not the same as watching a person poke at your thing and smile.
This is the moment a lot of devs start to feel the project slipping away from them without being able to say why. It feels like burnout. It's actually disconnection from the experience of the game. You've wandered into the machine room and you've been there for six weeks.
The structural fix is blunt. Before you start a task that will break the game for more than a day, branch. Commit a working version. If you're about to refactor the save system, make sure "last week's build" is one command away. Treat "the game runs end-to-end" as a non-negotiable daily constraint, the same way a real engineering team treats "the tests pass."
And schedule playtests. Weekly if you can get them. Even informal ones. Even with one person. The existence of the playtest forces you to keep the build playable, because you've already told someone they can come over on Thursday. That's structure. That's what we mean when we say finishing is structural: pre-commitments you can't quietly renegotiate with yourself at 1am.
Perfectionism is what isolation rewards
Perfectionism looks like high standards, but on a solo project it's usually something else: the only form of progress that nobody can argue with. When there's no one around to say "that's done, move on," your brain reaches for the one task it can always keep doing: polishing the thing in front of it. That's not a character flaw. That's what a month alone with no external signal will do to anyone.
In practice, you spend an hour adjusting the timing on a particle effect. You tweak it, you preview it, you tweak it again. At some point you start tweaking it back toward where it started. An hour gone, zero actual progress, and you feel like you worked. Repeat that pattern across twelve systems over four months and you've got a project that looks busy and is dying.
The math is brutal. At 80% quality, every additional hour of work produces visible improvement. At 95% quality, another hour produces a change so small no player will ever consciously notice. And somewhere past 97% you start going backward: you've lost perspective, your eyes are glazed, and the "fixes" you're making are just different.
The fix is a rule. Move on at 80-90% on any given pass, and save polish for after the whole game exists. You can always come back. You can't recover the months you burn polishing a mansion on top of a foundation that was never poured.
One devpod member put the working definition plainly: "I'm scared it's gonna break but 99% of the time it works and some people like it and it's good enough to push out." That's the voice you need in your head. It's not the voice of someone with low standards. It's the voice of someone who's shipped before, and who knows the next version of this thing can only be better than this one if this one exists.
Even the code behind Doom is full of hacks and workarounds. Carmack knows. Carmack shipped anyway. That's the move.
Kill your zombie projects
A zombie project is one you haven't officially quit but haven't touched in months. It's technically still "your current project" because you haven't made a decision, but the project file hasn't been opened since March. It's not alive. It's not dead. It's draining mental energy in a way that a fully killed project wouldn't, and it's quietly preventing you from committing to anything new.
Most indie devs have several. There's a verb people use when they describe their pile: graveyard. One dev on r/gamedev listed his out loud: "Here's my graveyard: Incremental game, Vampire Survivors-style, FPS arena wave-based..." You probably have a list like that. Some on GitHub, some in a projects/old/ folder you haven't opened on purpose. All of it haunting you.
The cost of zombies isn't the disk space. It's that some unconscious part of your brain is still allocated to them, generating low-grade guilt every time you start something new. What if I went back to that one? Was I wrong to leave? What if I just spent one more weekend on it? That's not strategic thinking. That's an open loop that never closes, and it steals focus from the project you're supposedly working on now.
The structural fix is blunt: kill them on purpose. Not "pause." Not "on hold." Dead. Make a list of every project you're "technically" still working on, be honest about which ones you haven't opened in 90 days, and kill everything except one. The one you keep should be the one you can realistically ship, which often means the smallest one, not the most ambitious.
Then, and this matters, tell someone you killed them. Post it. Announce it. External witnesses turn a private thought into a public commitment, which is exactly why r/INAT has a running joke about devs who say "I'll ghost you in around 2 weeks as everyone loses interest." Ghosting is the default state of solo work. Killing a project out loud is one way to interrupt it.
The urge to restart is the discomfort of progress
Halfway through any non-trivial project you will get an intrusive thought: "I've learned so much since I started. If I began again from scratch, I could do it so much better." This feeling is not a signal that you should restart. It's a signal that your project has grown complex enough to be uncomfortable, and your brain is offering you a dopamine-shaped escape hatch labeled "start over."
One developer rebuilt the same game three times. A month or two per rebuild. By the third version, he looked back at the first one and realized he actually liked it better. Three months converted directly into regret. Variants of that story show up in dozens of indie postmortems, and the common thread is never "I'm glad I restarted." The common thread is "I wish I'd kept going."
Messy code is normal. Every working game has it. Your operating system has it. The apps on your phone have it. Every codebase you've ever touched was held together by hacks, workarounds, and architectural decisions that looked fine in month one and tragic in month eight. That's not a failure. That's the shape of something real being built. A simple, elegant codebase usually means "nothing has actually happened yet."
The structural fix is a waiting rule. When you feel the urge to restart, wait a week. Don't argue with the feeling. Don't justify it. Write "considering restart" in a note with the date and keep shipping. The impulse usually passes inside seven days. If after a week it hasn't, write down specifically what a restart would fix, as a numbered list, and then ask, for each item: "can I fix this without starting over?" Nine times out of ten, yes.
There's a version of this where a restart is warranted: a fundamental engine change, a complete design pivot after playtest data. Those are rare. Most restarts are driven by the discomfort of complex systems and the hit of starting fresh. If your reason for wanting to restart is "the code is hard to work with now," that's not a reason. That's the job.
Consistency beats inspiration
The pattern that actually kills projects isn't under-work. It's oscillation. Solo devs love the one-man-army fantasy, the heroic week of eighteen-hour days that will catch up the schedule single-handedly. What the fantasy actually produces in practice is a burst, a burnout, two weeks of guilty avoidance, half a day of forced return, and another quit. Repeat for months until the project dies of accumulated avoidance.
Inspiration is great for starts. It's useless for finishes. Consistency isn't exciting, but it's the only thing that reliably ships games.
Consistency doesn't mean eight-hour days. It means showing up, even on the days you don't feel like it, even if all you do is ten minutes. The ten-minute trick is real and it works: tell yourself you'll work for just ten minutes, no more. That's all you're committing to. Usually the inertia breaks and you end up working for an hour. Sometimes you really do only ten minutes, and that's fine, because ten minutes of progress is not zero and the streak stays alive.
One indie dev coach put the diagnosis cleanly: "Nine out of ten times when someone approaches me about what they perceive as procrastination, it's actually a different problem in disguise." That different problem is almost always either "I don't know what to do next" or "I haven't given myself an actual deadline." Both are structural. Both are fixable. Neither is solved by trying harder.
And then there's the flip side, which sounds contradictory but isn't. Plan your downtime. Unplanned breaks generate guilt. Guilt generates avoidance. Avoidance kills the project. Planned breaks, on the other hand, are part of the process: you rest without guilt, you come back with energy, and the rhythm holds. After a major milestone, schedule the day off before you've earned it, so you don't feel like you're escaping.
The verbatim from one r/gamedev post says it plainly: "Real life wins more frequently, and the total amount of weekly commitment dwindles off." Real life will always win if you're the only one who notices when it wins. That's why the solo-versus-team debate is rarely the real question. The real question is whether anyone is waiting on your work by Friday.
Set a real deadline (and tell someone)
A deadline is the difference between "I'm working on a game" and "I'm shipping on June 12th." The first is a state. The second is a countdown. Something about a countdown, especially one other people know about, rewires how you make decisions. You stop adding. You start cutting. You stop polishing the edges and start shipping the essentials. You stop asking "what else could I add?" and start asking "what can I cut and still hit the date?"
Internal deadlines (the ones only you know about) barely work, because you can renegotiate with yourself at 2am and nobody will notice. External deadlines (announced in a dev log, submitted to a festival, posted on a Steam page) have teeth. Other people are expecting something. That pressure is productive, even when it's uncomfortable.
The structural insight most devs miss: a deadline is not a production quota. It's a decision-forcing function. Its job is to force choices. "I don't have time to add this" is a feature, not a failure. Without a date, every decision is a "maybe later." With a date, every decision becomes "yes or no, now."
One devpod host put it bluntly: "Procrastination really is putting off something that has a deadline. If you haven't decided on a deadline, you aren't even procrastinating. You're just drifting." Drifting is worse than procrastinating, because procrastinating at least implies a destination.
How to apply this.
- Pick a launch date. Not a "target window." A specific day. Write it down.
- Tell people about it. Dev log, Discord, email list, a friend. At least one person should be expecting a thing on that day.
- Work backward. What has to be true in month 5 if you want to ship in month 6? What gets cut if you fall behind? Pre-deciding the cuts keeps you out of panic mode at the end.
And if you need to push the date later, push it. Having a date to push from is completely different from not having a date at all.
The last 10% is the 90% nobody warned you about
If you've never shipped a game before, the last 10% of development will blindside you. It's not polishing the fun stuff. It's a mountain of unfun, release-critical work that nobody talks about until they're deep in it. Tom Cargill at Bell Labs captured it decades ago: "the first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time" (retrieved 2026-04-10). That's not a joke. That's a schedule.
Across the postmortems we've read, the dark work looks roughly like this:
- Finalizing every single sound effect: menu clicks, hits, footsteps, UI feedback
- Building the entire settings UI: volume sliders, control remapping, resolution, accessibility toggles, a credits screen
- Icons in five different sizes for five different platforms
- Splash screens in five different sizes for the same platforms
- Writing the Steam page description, short description, and tags
- Taking screenshots that actually make the game look good (harder than it sounds)
- Recording and editing a launch trailer
- Setting up the publisher account and filling out dozens of form fields
- Localization (even English proofreading takes longer than you'd believe)
- QA across different hardware: keyboards, controllers, GPUs, resolutions
- Balancing difficulty curves, economy, progression pacing
- Accessibility features: colorblind modes, subtitle sizes, reduced motion
- Legal work: EULA, privacy policy, age ratings through IARC
None of that is visible. None of it is fun. None of it looks impressive in a screenshot. It's all dark work: labor that produces no visible progress but is absolutely required for a real release. Devs who didn't know it was coming get crushed by it, because they're already six months in, already tired, and suddenly there's a tedious mountain between them and the finish line. This is the single most common quit point for near-finished games. The graveyard is full of games that were "almost done."
And the context around all this effort: SteamDB recorded roughly 17,889 to 19,000 game releases on Steam in 2024-2025, nearly half of which received fewer than ten user reviews (retrieved 2026-04-10). That's the level of noise your dark work has to cut through. A half-finished trailer won't do it.
How to apply this.
- Before you start your game, open the store page of a published indie game and count every element on it. That's your to-do list waiting in month 8.
- Budget at least as much time for the last 10% as you spent on the last major feature. Probably more.
- Don't save the dark work for last if you can help it. Build the settings menu early. Set up the Steam page the minute you're allowed. Spread the pain across the whole timeline instead of stacking it at the end.
Once you know the 90-90 rule exists, you can plan for the last 10% instead of being ambushed by it.
Finishing is a decision, not a state
Games are never "finished." They are abandoned at a level of quality you can live with. That sounds cynical, but it's the most freeing sentence in this guide. There is no moment where an alert pops up saying "game complete, 100%, ship it." That moment does not exist and has never existed. There will always be one more feature you wish you'd added, one more system you want to refine, one more polish pass.
This means finishing is not something that happens to you. It's a decision you make on a specific day, and the decision is structural too. You can set yourself up to make it, or you can set yourself up to defer it forever.
One setup that works: before development begins, write a "done" list. The specific features and content that, when they all exist, constitute a shippable game. Write it as a feature list, not a quality bar. Quality bars move. You'll always want things "a little better." Feature lists can be held firm: this level is in, this mechanic is in, this boss is in, and everything else is post-launch content.
Then, during development, every time you catch yourself adding "just one more thing," check it against the done list. If it's not on the list, it doesn't go in the 1.0 build. It goes on a separate "maybe later" list. You can add it in a patch. You can add it in version 1.1. You just can't add it now, because "now" is how you end up with nothing.
Some devs hide in perpetual development forever because an unreleased game can't be criticized. "It's not ready yet" is a shield. But the cost of hiding is enormous: your game never reaches the people it was made for, and you never get the one thing that makes all the hard work worth it, which is watching a stranger play your game and react to it.
Even Halo 2 shipped with half its planned content cut. Destiny shipped after a sideways redesign. If Bungie can ship an imperfect game, so can you. The French poet Paul Valéry said it long before any of us: "A work is never finished, only abandoned." Abandon yours on purpose. Abandon it on a specific date. Abandon it for the people who are waiting to play it. That's what shipping is.
Questions indie devs ask about finishing
A handful of questions come up over and over again in indie dev circles, the kind that don't fit cleanly into any single section above but keep getting asked. Quick, direct answers below.
What counts as "finished" for a first indie game?
A first indie game is finished when (a) the entire core loop works end-to-end, (b) a stranger can install it, launch it, play it, and exit without getting stuck, and (c) a version of your "done" list, written before development started, is fully checked off. "Finished" is not "perfect." It's "shippable." If it runs and it's on your pre-written done list, it ships.
How long should it take to finish an indie game?
Shorter than you think, longer than you planned. A realistic first indie game is two to six months of focused work, not two to six years. If your estimated timeline is longer than a year and this is your first shipped title, your scope is almost certainly wrong. Cut features until the honest estimate fits inside six months, then add 50% because humans are terrible at time estimation.
Should I scrap a project I hate but have already invested in?
Probably yes. The "I've already invested so much" feeling is the sunk-cost fallacy dressed up as responsibility, and finishing a project you hate rarely produces a good game. Better question: "would I start this project today, knowing what I know now?" If the answer is no, kill it on purpose (see section 6) and start something small you can actually finish.
How do I know if I'm procrastinating or actually stuck?
If you know the next concrete step and you're not taking it, you're procrastinating. Usually because the step is boring, scary, or unclear at a level of detail you haven't admitted. If you don't know the next concrete step, you're stuck, and the fix is to make the step smaller until it's obvious. Stuck devs need a smaller task. Procrastinating devs need a deadline.
What percentage of indie games actually ship on Steam?
There's no clean number, because unreleased games don't get counted. What we do know: 48% of 23,485 studied Steam games had a delayed initial release, and nearly half of the ~18,000 games that shipped on Steam in 2024-2025 received fewer than ten reviews (both retrieved 2026-04-10). Those are the ones that shipped. The real "attempted but abandoned" number is much larger and lives in folders nobody posts about.
Is it better to finish a small bad game or a big good one?
The small finished game, always. A finished small game teaches you more about shipping than three unfinished big ones combined. You learn things on the last 10% that you cannot learn any other way. You also build identity capital as someone who ships, which matters a lot for being taken seriously by potential teammates on your second game. Nobody recruits from a portfolio of prototypes.
You don't have to finish alone
Everything in this guide is harder when you're doing it alone. Scope discipline is harder when there's no one to push back on your ideas. Consistency is harder when no one notices if you skip a day. Deadlines are optional when only you know about them. Dark work is soul-crushing when you're the only one grinding through it. And deciding to ship is terrifying when you're the only person who has to make the call.
Look back at the patterns in this guide. Zombie projects. Restart spirals. Week-6 drift. Perfectionism loops. The silent breakdown of the playable build. The oscillation between burst and burnout. Every one of them gets worse in isolation, and most of them get better the moment there's one other person in the loop with you.
The developers who consistently finish games tend to share one structural trait: they're not doing it alone. Not necessarily on a big team. Often just one other person. A co-dev. An accountability partner. Someone who's counting on the level design being done by Friday. Someone who notices when they go quiet. Someone who has to see the playable build on Thursday because they promised to play it.
This isn't a new idea. It's the idea the rest of game development already knows. Studios don't exist because studio owners enjoy payroll. They exist because finishing a game is a job that mostly doesn't get done in a vacuum. The question for indie devs has always been: how do you get the structural benefits of a studio without giving up your IP, your creative control, or your nights and weekends?
That's the question Clowdr exists to answer. It's a managed setup where indie devs team up with real structure (a playbook, real accountability, clear agreements in writing) to actually ship. Not a dead Discord project where everyone loses interest by week 3. A place designed around finishing. Contributors keep full rights to their work. Artists and composers get brought in early as creative partners, not service desks at the end of a project. Every agreement is written down before anyone contributes anything.
One r/gamedev post title captured what it feels like from the inside: "cursed to work alone." That's not a character trait. That's what happens when you try to do a multi-person job by yourself for long enough.
You're not lazy. You're unsupported.
If you've read this far, you already know the patterns. You've probably lived most of them. Now it's about breaking them, and the cleanest way to break them is to stop trying to do this alone.
Join the Clowdr waitlist and ship the next one with people who are waiting on your work by Friday.