Work-for-Hire vs Revenue Share for Indie Teams

Pay cash (work-for-hire) for bounded, replaceable work and when you can afford it — you keep ownership simple and nobody resents anybody. Share revenue when cash is short and the collaborator takes real ongoing risk with you. Hybrids — a reduced fee plus a small royalty — are often the honest middle. That's the short version — the sections below get into the how, the why, and the mistakes worth dodging.

What each model is actually trading

Work-for-hire trades money for clean ownership: the contractor gets paid regardless of the game's fate, you keep all upside and all risk, and rights transfer (if the contract says so — make it say so). Revenue share trades upside for runway: no cash today, but you've added a permanent stakeholder whose share outlives their involvement.

Neither is morally superior. The mismatch failures are: rev-share offered as fake currency for work you'd never pay for, and work-for-hire used to underpay someone carrying genuine project risk.

Rev-share math most teams skip

A 10% share of a game that earns the indie median is worth a few hundred dollars — be honest about that when recruiting, because 'points' on an unshipped indie game are lottery tickets, not compensation. Conversely, 10% of a hit dwarfs any fee, which is why bounded contributors usually prefer fees and core partners prefer shares.

Whatever you promise, define the base precisely (after platform cut? after costs?), the duration, and whether DLC and sequels count. Ambiguity here is the seed of every post-launch friendship implosion.

Hybrids and the paperwork either way

The deal that keeps small teams together: a below-market fee that respects the work today, plus a small royalty that respects the bet. Composers and artists accept it constantly; it aligns everyone without making anyone a major shareholder.

In all cases, paper it: scope, payment, IP transfer or license, credit, and exit terms. One page suffices. The contract isn't distrust — it's the shared memory that survives two years of Discord messages.

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.