How to Spot Rev-Share Red Flags Before You Join an Indie Game Project

Last updated: 2026-04-19

Rev-share is not automatically a scam. But a lot of indie game rev-share projects die for the same reasons: no shipped proof, no written terms, fantasy split math, and a founder who wants your work before they want accountability.

That is the point of this checklist. Use it before you give away code, art, music, design work, or six months of your life. By the end, you should be able to sort any pitch into one of three buckets: join, renegotiate, or walk away.

What you need before you start

• The original post, pitch, or DM thread
• Any build, footage, task board, or repo the team claims already exists
• Enough patience to ask awkward questions before you say yes

1. Check whether anything exists beyond a pitch

What to do: Ask for the smallest proof that this project is real. A playable prototype. A private build video. A repo with recent commits. A task board with completed work. A shared folder with assets that match the claimed progress. You are not asking for polish. You are asking whether anything exists beyond a lore dump and a recruiting post.

Why it matters: Most dead rev-share projects do not die in production. They die before production starts. The team talks about the eventual Steam page, the dream soundtrack, or the twelve-class combat system, but there is no ugly prototype underneath it. If there is no proof of execution yet, the "share" part is still imaginary.

Watch for: Big-genre claims with tiny evidence. "MMO." "Open world." "Roguelike deckbuilder extraction shooter." A lead who has a Notion doc, a Discord server, and a logo, but no narrow slice of the game working in motion.

2. Ask for written scope, contribution, and exit terms before you discuss percentages

What to do: Get the core terms into writing before anyone starts serious work. Keep it plain English. Who is building what? What counts as done? What happens if someone leaves? Can contributors reuse their unpaid work elsewhere? When do terms get revisited? One page is enough if it answers the real questions.

Why it matters: A founder who wants to debate percentages before defining scope is asking you to negotiate fantasy value. You cannot price a contribution that nobody has described. Written terms force the team to define the project as a real thing instead of a mood.

Watch for: "We'll sort the paperwork out later." "Let's see how the vibe is first." "We don't need contracts, we're all friends here." Those lines do not remove risk. They move all of it onto the contributor with the least bargaining power.

3. Run the split math and team-size reality check

What to do: Write down the full team, the proposed split, and the most realistic outcome you can imagine for the game. Not the best case. The normal case. If ten people are sharing a future payout from a first-time indie project with no funding, no audience, and no release plan, treat it like a lottery ticket. Then ask whether the hours make sense.

Why it matters: Rev-share pitches get easier to sell when the money stays abstract. The moment you turn it into numbers, the spell breaks. "Twenty percent of zero is still zero" is blunt because it is usually true. Tiny slices of hypothetical revenue are not the same as compensation.

Watch for: Huge teams with everyone on rev-share. Equal splits for wildly different workloads. No marketing owner. No budget for audio, QA, or ports. A pitch that promises future upside because it cannot justify the present structure.

4. Verify ownership, credit, and portfolio rights if the project stalls

What to do: Ask who owns the code, assets, and recordings if the game never launches. Ask whether every contributor can still show their work in a portfolio. Ask how credits get locked in. Ask what happens to shared files if one person leaves. Do this before the first meaningful deliverable, not after.

Why it matters: This is where artists, composers, and specialist contributors get burned hardest. If the project dies, your time is already gone. The least you should keep is the right to show what you made, keep a credit trail, and avoid getting trapped in someone else's dead repo.

Watch for: A lead who wants exclusive rights to unpaid work. A ban on portfolio use until launch. Vague answers about credits. A promise to "figure it out if we get there." If they cannot define ownership when things go wrong, they have not designed a real collaboration. They have designed a dependency.

5. Look for milestone discipline instead of hype

What to do: Require one short milestone before you commit to the full project. Two weeks is a good stress test. Pick something that a third person can understand in one glance: a combat loop in a test room, one character with movement and attack states, one UI flow that actually runs, one music cue integrated into a scene. Then see whether the team ships it.

Why it matters: Teams that cannot define a two-week deliverable do not suddenly become disciplined at month four. The short milestone is not busywork. It tells you whether the lead can scope, whether contributors respond, and whether decisions move without ten hours of theory.

Watch for: Endless calls. Constant role expansion. New systems added before the first system works. "We need the full team before we can start." No, you do not. You need one small thing finished by a date.

6. Test the lead for replacement behavior and theft risk

What to do: Ask where files live, who controls access, how backups work, and how contributor work is tracked. Ask who can remove someone from the repo, the shared drive, the build pipeline, and the credits list. Ask what stops a lead from taking the work, changing passwords, and continuing without the original contributor.

Why it matters: Nice founders can still build unsafe structures. Unsafe structures let bad founders do damage fast. The scariest rev-share stories are not about awkward communication. They are about a contributor shipping the hard part, then getting cut out at the moment the project becomes useful.

Watch for: One person controlling every account. Requests for final source files before any terms are signed. No shared changelog. No contribution history. A founder who says "trust me" while keeping all the power to lock everyone else out.

7. Decide whether to join, renegotiate, or walk away

What to do: Make the call based on structure, not charisma.

Join if the project already has real proof, written terms, sensible scope, portfolio protection, and a short milestone that people actually hit.

Renegotiate if the project looks promising but one core piece is missing. Maybe the prototype exists but the exit clause is weak. Maybe the team is strong but the split math is nonsense. Fix the weak point before you contribute more.

Walk away if two or three of these red flags stack up at once. No artifact, no written terms, giant scope, fuzzy rights, defensive answers, and pressure to "just get started" is not rough-around-the-edges ambition. It is the standard setup for unpaid work that never ships.

Why it matters: The hardest part is usually not spotting the problem. It is admitting that the pitch still fails after the call, the shared excitement, and the founder's confidence. Good collaborators do not prove loyalty by ignoring obvious structural risk.

Watch for: Yourself rationalizing the red flags because the game sounds cool, the art style matches your taste, or you are tired of working alone. Loneliness makes bad deals look better than they are.

Common pitfalls

Waiting for the agreement after the work starts. Once real work exists, the person holding the files has the power. Get the terms in place first.

Treating passion like proof. A passionate founder can still be chaotic, territorial, or incapable of shipping. Excitement is not a substitute for structure.

Accepting a percentage without a boundary. If the project scope keeps growing, your unpaid obligation grows with it. Tie contributions to milestones, not to infinite possibility.

What to do next

If this checklist just killed a project you were about to join, good. That is cheaper than losing six weekends to a dead Discord server.

If you are still sourcing teammates, read How to Stop Getting Ghosted on r/INAT next. If you want a better filter for serious collaborators, go to How to Find Reliable Teammates for Your Indie Game. If you are still deciding whether to stay solo at all, read Solo Dev vs Team. If you are an artist or composer who is tired of building portfolio pieces for games that never launch, read Game Artist Portfolio Graveyard.

If you want a setup with clearer terms, contributor rights, and people who are here to finish, join the Clowdr waitlist.