Can you make a living making indie games? An honest look
At some point most developers ask the same question: could this be the job? Not a hobby that occasionally pays for a monitor, but the thing that covers rent every month, for years, without a salary underneath it. It is a fair question and it deserves a better answer than either the success stories or the doom threads give you.
The honest answer is that some people do it, that far more people try than succeed, and that the difference is only partly about how good the games are. A lot of it is structural — how the money actually arrives, how uneven it is, how much of a game's price ever reaches the developer, and how wide a market a single game is sold into.
This article is about that structure. There are no revenue figures in it, because any number quoted as typical would be a fiction assembled from games that are not yours. What is worth knowing is the shape of the thing, which is stable even when the numbers are not.
How indie income is actually shaped
The first thing to internalise is that the distribution is extremely skewed. A small number of titles capture a very large share of the money in any given year, and the typical release earns dramatically less than the average release. This is why averages are useless here — the average is dragged upward by outliers that no plan can reproduce on purpose. If you plan around the average, you are planning around somebody else's lottery ticket.
The second is that the price on the store page is not what you receive. Storefronts take a percentage of every sale, which is published in each store's terms. Consumption taxes and VAT come out depending on where the buyer is. Refunds are subtracted. Regional pricing means a copy sold in one country brings in materially less than the same copy sold in another, by design. Payments arrive on a delay, often a month or more after the sale. And developers outside the country of the storefront usually deal with withholding on top of all that, which is where tax treaties and forms like the tax interview in a store's back office come in — the mechanics vary by country, and the details are worth confirming with an accountant and the official documentation rather than an article.
The third is that the income is lumpy rather than monthly. A typical pattern is a launch spike, a steep decline, and then a long tail punctuated by spikes during discount events. That means the practical question is not 'can a game earn a year of living costs' but 'can it do so in a shape I can actually live on', which is a question about savings and runway as much as about sales.
What the people who keep going do differently
The most consistent difference is scope discipline. A game that takes four years costs four years of living expenses before it can return anything, and it has to succeed at a level proportional to that. The developers who sustain a career mostly ship at a pace that lets them survive a title that underperforms — because they will have one.
The second is that they do not rely on a single income line. Contract work, ports, publisher advances, platform funding programmes, tools or assets sold to other developers, and revenue from older titles all show up in the finances of people who have been doing this for a decade. This is not a compromise on the dream; it is what makes the dream survivable during the years when a release does not land.
The third is that they treat it as a business from the beginning. Separate accounting, tracked expenses, an understanding of how their country taxes this kind of income, and enough runway that a delayed payment is an inconvenience rather than a crisis. This is unglamorous and it is the difference between a bad year ending a career and a bad year being a bad year.
The fourth is audience continuity. A developer whose second game launches to the people who liked the first one starts from a fundamentally different position than one starting from zero again. That continuity is built during and after each release — a mailing list, a community, a following on whatever platform suits you — and it is one of the few assets in this business that does not depreciate.
Widening the market a single game is sold into
Here is a lever that gets far less attention than it deserves, precisely because it is not about making the game better. Once a game exists, the cost of selling it to more people is far lower than the cost of making another game. Every additional market you can reach with the same build is revenue against work you have already done.
In practice the widest available lever is language. Digital storefronts already sell worldwide by default; distribution stopped being the hard part a long time ago. What remains is that a player who cannot read your store page will rarely buy, and a player who cannot read your tutorial will rarely stay. Adapting a game and its store page so they read naturally in another language is called localization, and for a small game it is one of the few investments that raises the ceiling without touching the design.
The reason this matters specifically for survival is arithmetic. If one language reaches a certain slice of the players who would enjoy your genre, reaching two or three slices does not require you to build a second game, find a second idea, or spend another two years. It requires text, and text is the cheapest part of a game to duplicate.
It is not free and it is not automatic. Translation costs money or time, longer strings break user interfaces that were only ever tested in one language, some scripts need fonts you do not currently ship, and every update afterwards inherits the commitment. But the sizing is flexible: a translated store page is a few hundred words and functions as a demand test, while the full game is a much larger decision you can defer until that test comes back.
Multiple titles and the back catalogue
One release almost never makes a career. What tends to make one is a catalogue, because catalogues behave differently from individual games. Older titles keep earning during discount events. A new release drives players back to your earlier work, which means every launch lifts the entire catalogue rather than just itself. And the marginal cost of each new game drops as your own engine layer, tooling, pipeline, and release process get reused instead of rebuilt.
This is also where the earlier point about widening markets compounds. A catalogue of three games available in five languages is a much larger business than three games available in one, and the work to get there is incremental — done once per game, reused every time that game goes on sale for the rest of its life.
Thinking in catalogue terms also changes what counts as failure. A game that does not return its development time is not automatically a wasted year if it built tooling you now reuse, an audience that follows you to the next thing, and a release process you now know how to run. Those are assets even when the revenue line is disappointing.
What to actually do on your first title
Do not quit anything yet. The first release is where you learn the machine — store pages, review processes, tax forms, discount scheduling, patching, refunds, support requests — and learning it while your rent depends on it is a bad trade. Keep the income you have until the numbers, not the hope, say otherwise.
Ship something small enough to actually finish. A finished small game teaches you the entire pipeline end to end; an unfinished ambitious one teaches you very little and costs far more. The goal of the first title is a complete cycle, not a hit.
Set the business side up before you need it: separate the finances, keep records from day one, and get advice appropriate to your country about how this income is taxed and what forms a foreign storefront will ask you for. This is exactly the sort of thing that is boring in month one and expensive in month twelve.
And make one technical decision early, because it is very cheap now and very expensive later: keep your game's text out of your code, in files you can export. You do not have to decide today which languages you will support, or whether you will support any. You only have to avoid building a game where the answer is permanently no, because when a market does show up asking for your game in their language, the difference between a two-week job and a two-month one is a decision you made at the beginning.
So — can you?
Some people can and do, and there is no honest way to tell you in advance whether you are one of them. What can be said is that the people who last are rarely the ones who bet everything on a single release. They ship repeatedly, keep their costs survivable, build an audience that carries between projects, and sell each game into as wide a market as it can reach rather than the narrowest one.
That last part is the one most often left out of the conversation, and it is the one you have the most control over after the game is already made. Making a good game is necessary and it is not sufficient. Being findable, readable, and buyable by everyone who would have liked it is the other half of the job.