Quick answer: Anywhere from one to a thousand: solo devs ship beloved games yearly (scoped to one person's strengths), duos and trios are indie's sweet spot, and each person added buys capacity while taxing it with coordination. The real question inverts: given the people you have, what design fits? Teams fail by choosing designs for the team they wish they were.
Anywhere from one to a thousand: solo devs ship beloved games yearly (scoped to one person's strengths), duos and trios are indie's sweet spot, and each person added buys capacity while taxing it with coordination. The real question inverts: given the people you have, what design fits? Teams fail by choosing designs for the team they wish they were. That's the short version — the sections below get into the how, the why, and the mistakes worth dodging.
What each size actually ships
Solo: focused games leaning on one or two strengths — a distinctive mechanic, a strong aesthetic, systemic depth over content volume (Stardew Valley is the famous outlier that proves the years-long cost). Duo/trio: the classic indie scale — complementary skills, near-zero coordination overhead, vertical-slice-quality games with real content. Five to ten: multi-year ambitious indies, now with management as a real job. Beyond that: you're a company, with a company's problems.
The pattern across scales: successful teams design for their shape — solo devs pick solo-shaped games. The graveyard is full of three-person MMOs.
The coordination tax is real and nonlinear
Each added person brings hours but costs alignment: communication paths grow combinatorially, decisions need venues, vision needs documents instead of telepathy. Going from two to four people doubles capacity but quadruples the ways to misunderstand each other — which is why a focused duo regularly outships a loose six.
Add people for missing capabilities, not raw speed: the artist who unlocks a look you can't achieve beats two generalists who half-overlap with you. And every addition should clear the bar of 'worth the new overhead', which is higher than it feels.
Contractors bend the math
The modern indie team is elastic: a tiny core plus rented expertise — capsule artist for a week, composer for a soundtrack, porting house for consoles, trailer editor for launch. You get specialist quality without permanent payroll or permanent coordination cost, which is how two-person studios ship games that look like ten-person games.
The core skill becomes specification and integration: knowing what to buy, describing it well, and weaving the results into a coherent whole. Teams scale best by buying bounded things and keeping the unbounded thing — the vision — small and owned.
Scope is the boss fight
Almost no indie game dies from bad code or bad art. They die from being half of a too-big idea. The skill that separates shipped games from abandoned ones is ruthlessly matching the design to the time and energy you actually have — not the time you wish you had.
Write down your honest weekly hours, halve them for life's interruptions, and scope to that. A small game that exists beats a big game that doesn't, every single time.
Momentum is a resource — budget it
Progress you can see is fuel. Long stretches of invisible work — refactors, systems with no on-screen result — drain motivation even when they're necessary. Good project plans alternate: one stretch of plumbing, then something you can watch move on screen.
When motivation dips, shrink the loop. Pick the smallest change that makes the game visibly better today. Shipping anything, even a menu fix, restarts the engine.
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.
Scope to the hours you really have, then ship the small game that fits them.