Making a Game With Friends (Without Losing Them)

Friend teams die from unspoken expectations, not from disagreements: have the awkward conversations first — hours, roles, who decides what, what happens to money and ownership if someone leaves — and write them down while everyone likes each other. The contract isn't distrust; it's a gift to the friendship from the people you currently are. That's the short version — the sections below get into the how, the why, and the mistakes worth dodging.

The conversations that feel unnecessary until they're urgent

Before real work starts, answer together: How many hours is each person actually committing (not aspiring)? Who has final say in which domain? Is this a hobby or an attempt at a business — and what would change that? What happens if someone gets a job, a kid, or bored? Mismatched silent answers to these questions are the actual cause of most friend-team explosions.

Expect the answers to differ — that's the point. A 30-hour partner and a 5-hour partner can absolutely ship together, but only with that asymmetry priced into ownership and decision rights rather than discovered through resentment.

Structure is kindness: roles, decisions, and vesting

Equal friends still need unequal authority by domain — someone owns design calls, someone owns tech calls — or every disagreement escalates to a friendship referendum. Pair it with a written split (weighted to real commitment), vesting over time or milestones so early departure doesn't haunt the cap table, and a named tiebreaker mechanism for genuine deadlocks.

One page covers it: names, split, vesting, roles, IP ownership, exit terms. Friend teams that skip the page aren't braver; they're just pre-committing future-them to negotiate it during a fight.

Run the friction professionally, protect the friendship deliberately

Critique the build, never the person; do it in scheduled reviews rather than ambush messages; and keep one channel (or one evening) that is explicitly not about the game — teams that become only coworkers lose the thing they formed to protect. When someone underdelivers, address it in weeks, not months: stored resentment compounds at friendship-destroying rates.

And if it stops working, end the project before it ends the relationship. A clean 'this isn't working, let's wind it down' with the agreed split honored is a success story compared to the alternative everyone has watched happen.

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.

Decide how you'll know it's working

Every project needs a definition of done that isn't a feeling. Pick the few signals you'll trust — playtesters finishing the demo, crash-free sessions, wishlists per week — and check them on a schedule. Otherwise you'll steer by whichever anxiety is loudest that day.

This is also the honest defence against endless polishing. When the signals say players get through it, enjoy it, and nothing breaks, the feature is done. Move on.

The quiet work that protects all of this

Everything in this post gets undone by an unstable build. A great store page, a clever marketing beat, a perfect jam entry — none of it survives 'crashed twice, refunded'. Stability isn't a feature players praise, but it's the floor everything else stands on.

Give yourself visibility before you need it: crash reports with stack traces, a simple way for players to flag issues from inside the game, and a habit of fixing the top recurring error before adding anything new.

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.