Quick answer: Quit when the numbers work without optimism: runway for the realistic dev time plus a year, evidence of demand (wishlist velocity, an audience, revenue from a previous release), and a fallback you'd genuinely use. Excitement, a finished prototype, or hating your job are reasons to want to quit — not evidence you should.
Quit when the numbers work without optimism: runway for the realistic dev time plus a year, evidence of demand (wishlist velocity, an audience, revenue from a previous release), and a fallback you'd genuinely use. Excitement, a finished prototype, or hating your job are reasons to want to quit — not evidence you should. That's the short version — the sections below get into the how, the why, and the mistakes worth dodging.
Evidence first, resignation second
The healthy sequence inverts the fantasy: build something part-time, put it in public, and let demand signals accumulate — wishlists growing without paid pushes, a demo with strong completion, a community asking for more, ideally money. Quitting accelerates a validated project; it does not validate an unvalidated one.
A useful bar: if the game's public signals wouldn't convince a skeptical friend to invest savings in it, they shouldn't convince you to invest a salary in it.
The runway equation with the sad constants
Realistic version: (savings ÷ monthly burn) must cover your dev estimate times two, plus six-plus months post-launch, because revenue arrives slowly even for games that do fine — first payouts lag, and the long tail is where indie money lives. Add health costs, taxes on eventual income, and the morale cost of watching the account drain.
If the equation fails, the answer usually isn't 'don't' but 'not yet, and smaller': cut scope until the timeline fits the money.
The middle paths beat the cliff
Going part-time, negotiating a sabbatical, contracting three days a week, or saving aggressively for a defined attempt window all buy development speed without betting the house. Many shipped indies were made by people who never quit at all — the day job was the publisher.
If you do jump: set explicit checkpoints ('at month six, wishlists above X or I take contract work') in writing, before motivated reasoning owns the data. The plan you make while employed is smarter than the one you'll improvise while burning savings.
Cheap experiments beat expensive certainty
Most business questions in indie development — price, platform, publisher, marketing spend — can be tested small before they're answered big. A two-week itch.io experiment, one festival demo, or a single contractor invoice teaches you more than a month of forum threads about what other people's games did.
Treat every irreversible decision with suspicion and every reversible one with speed. The studios that survive aren't the ones that guessed right the first time; they're the ones that made their guesses cheap.
Protect the downside first
Indie game revenue is lumpy and unpredictable, and most advice quietly assumes a hit. Plan for the median outcome instead: a launch that earns modestly and grows slowly. Keep fixed costs low, keep some runway, and make deals you could live with if the game sells a tenth of your hopes.
None of this is pessimism — it's what lets you take real creative risks. A developer who can afford to miss is a developer who can afford to be interesting.
Plan for the bugs you won't see coming
Whatever else you take from this, build yourself a way to hear about problems. Once your game is on other people's machines, most failures happen out of sight: the crash on hardware you don't own, the save that corrupts once in fifty exits, the bug players mention in a review instead of a report.
A lightweight crash and bug reporting setup — even just Bugnet's free tier wired into your engine — turns that silence into a fixable list. The devs who look calm at launch aren't luckier; they just see their problems earlier.
Putting it to work
Don't try to act on all of this at once. Pick the one change that costs you the least and pays the most this week, do it, and see what actually happens before reaching for the next.
Most of this rewards steadiness over intensity. A small improvement made every week, checked against how real players respond, outruns any single burst of effort — in this corner of game development and every other one.
Make the guesses cheap, the agreements written, and the runway longer than the plan.