Running a Catalogue as a Team of Two
A two-person team is not a small version of a large team. Here is what we did differently, what we said no to, and the pace that turned out to be sustainable.
Hage Game is a two-person operation. One of us writes the code; the other writes the prose, designs the page templates, and edits everything. There is no project manager, no community team, no QA, no marketing. We have built 25 games and 30 articles in two languages this way, and the structure has worked — but it has worked in specific ways that are worth describing, because the assumption that a two-person team is "smaller and cheaper" but otherwise the same as a larger team is wrong.
The hard split
The first decision we made — and the one we have stuck to most rigorously — is that one of us does code and only code, and the other does everything else. There is no overlap. The technical co-founder never edits an article; the editorial co-founder never opens a code editor. We considered the hybrid model where both people do both, and rejected it for one reason: context-switching costs us much more than specialisation costs us.
A game's code and a game's review are different kinds of work that engage different parts of the brain. Switching between them within a day produces lower-quality work in both than concentrating on one for several days. By splitting permanently, we make sure each of us is operating in their primary mode every day, with no transition tax.
This requires trust. The editorial co-founder must trust that the code is doing what it claims to do; the technical co-founder must trust that the review accurately describes the game. We do not double-check each other's work because we cannot — we genuinely do not have the time, and even if we did, the act of double-checking would be the context switch we are trying to avoid. We rely on each other's judgement absolutely. Two people who cannot do this should not run a two-person studio.
What we deliberately do not do
A two-person team's most important skill is saying no. We have said no to: building a backend, building user accounts, building social features, building a leaderboard, building push notifications, supporting more than two languages, supporting more than the modern browser baseline, marketing the games on social media, running ads, accepting submissions from external developers, having a comments section, having a forum, having a Discord server, having an email newsletter.
Each of these is something a larger team would have done. Each is reasonable on its own. None of them is reasonable for two people. We have stayed alive as a project by being very strict about what we are: a small editorial outfit publishing original browser games and writing. Everything else, we have explicitly chosen not to be.
The compounding small choices
A different model for two people is to make each piece of work generate the next piece. We do not build games and then build articles about them; we build the game and the article together, in the same week, because each makes the other better. Writing the review forces the code reviewer to think clearly about what the game actually is, which often surfaces small fixes to the code. Writing the code forces the writer to engage with the actual mechanic, which produces a more accurate review.
This is not "agile development" or any other named methodology. It is the natural way a two-person team works when both people are within shouting distance of each other (literally or virtually) and the decisions are small enough to be made in five minutes. The overhead of larger teams comes from coordinating people whose work depends on each other; two people can coordinate by talking.
What we have learned about pace
The pace of a two-person team is irregular. We do not produce one game per week consistently. We produce a burst of three games in five days, then nothing for a week while we write the articles, then a burst of more games. Trying to enforce a steady cadence would slow us down by forcing context switches we have not yet earned. Letting the pace breathe — accepting that productive bursts are separated by quiet stretches — is the only sustainable rhythm we have found.
The lesson generalises beyond games. Most small teams over-engineer their process trying to look like a larger team's predictability. The honest answer for two people is to do less process and more work, and to trust that the bursts will average out across a project.
Published · 14 May 2026 · Written and signed by Bill