Quick answer: Two people is the most efficient studio size game development has — zero meetings overhead, total context sharing — if you split decision domains cleanly (one final word per area), keep a lightweight weekly sync despite feeling like you don't need it, and consciously cover the third-person gaps: marketing, testing, and the tiebreaker vote you don't have.
Two people is the most efficient studio size game development has — zero meetings overhead, total context sharing — if you split decision domains cleanly (one final word per area), keep a lightweight weekly sync despite feeling like you don't need it, and consciously cover the third-person gaps: marketing, testing, and the tiebreaker vote you don't have. That's the short version — the sections below get into the how, the why, and the mistakes worth dodging.
Divide domains, not tasks
The stable duo pattern is sovereignty: one person has final say on design/product, the other on tech/execution (or art/code, or inside-game/outside-game — the axis varies, the clarity doesn't). Both contribute opinions everywhere; each defers in the other's domain. This kills the deadlock problem a two-person team structurally has — without it, every disagreement is a 1-1 tie with no court of appeal.
Write the domain map down, including the awkward shared zones (scope, money, hiring) where you'll need explicit consensus and a fallback ritual — even 'we sleep on it, then the domain-owner decides' beats unstructured stalemate.
Sync weekly even though you talk daily
Duos drift precisely because communication feels constant: you chat all day about tasks and never about trajectory. A 30-minute weekly sync with three fixed questions — what shipped, what's blocked, are we still building the same game? — catches the divergence daily chatter hides.
Add a monthly 'state of the studio' conversation for the bigger gauges: scope confidence, money runway, morale, and whether the workload split still feels fair. Fairness drift is the duo's silent killer; surfacing it quarterly is much cheaper than surfacing it during a fight.
Cover the missing third person on purpose
Two-person teams reliably under-resource the jobs neither person owns: marketing, playtesting logistics, QA, and bookkeeping. Assign each orphan explicitly (even 'you own marketing, badly, four hours a week' beats nobody owning it), automate what tools can carry — builds, crash reporting, backups — and buy the rest in small contractor doses.
External feedback also needs deliberate plumbing: a duo agrees with itself too easily. Regular stranger playtests and a few trusted dev peers reviewing builds substitute for the dissenting voice you didn't hire.
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.