How to Split Revenue With Collaborators

Pick a model deliberately — equal splits for equal partners, weighted by contribution or role otherwise, or flat fees for bounded work — and write it down with names, percentages, payment mechanics, and what happens if someone leaves. The split conversation is exponentially cheaper before revenue exists than after. That's the short version — the sections below get into the how, the why, and the mistakes worth dodging.

Match the model to the reality

Equal splits fit genuinely equal partnerships of similar time and risk. Weighted splits fit unequal commitments — full-time versus weekends, two years versus three months. Flat fees fit bounded contributions: a composer's eight tracks, an artist's capsule. Hybrids (fee plus small royalty) handle the middle.

The classic failure is defaulting to equal because the conversation is awkward, then watching resentment grow as contributions diverge. The awkward hour now buys years of peace.

Decide the ugly cases while everyone's friends

The agreement earns its keep on the bad days, so answer them in writing: someone leaves mid-project (do shares vest over time? freeze at departure?), someone stops contributing but won't quit, the game adds DLC or a sequel (does the split carry?), someone wants out entirely (can others buy them back?).

Vesting tied to milestones or time is the single most useful clause for hobby teams — it makes 'left after a month, owns 25% forever' impossible by construction.

Mechanics: who collects, who pays, who sees

One person or entity receives storefront payouts and redistributes — name them, define the schedule (quarterly matches platform reporting), and give everyone visibility into the raw reports so trust never depends on trust. Decide gross-vs-net precisely: split after platform cut, after shared costs like fees and contractor invoices, with the cost list written.

Cross-border teams: the payer may have withholding or reporting duties on payments to others. It's exactly the boring detail that professionalizes a friend group into a studio.

Protect the downside first

Indie game revenue is lumpy and unpredictable, and most advice quietly assumes a hit. Plan for the median outcome instead: a launch that earns modestly and grows slowly. Keep fixed costs low, keep some runway, and make deals you could live with if the game sells a tenth of your hopes.

None of this is pessimism — it's what lets you take real creative risks. A developer who can afford to miss is a developer who can afford to be interesting.

Get unglamorous things in writing

Splits, deadlines, deliverables, who owns what if the project dies — the awkward conversations are dramatically cheaper before money shows up. A one-page agreement between friends feels like overkill right up until it's the only thing that saves the friendship.

You rarely need a lawyer for a first project, but you do need clarity. Write down what was agreed, date it, and make sure everyone has a copy. Future-you will be grateful.

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.

Make the guesses cheap, the agreements written, and the runway longer than the plan.