What is Revenue Sharing?

I was on a project with contributors spread across two years. It started out awesome. Everyone tracked their work in a shared Excel spreadsheet. Everyone was supposed to log their hours. Guess how that ended up?

Spoiler alert: I have no idea. The only thing I know for sure is that a lot of work was untracked or tracked inaccurately, and the whole thing became unusable as the project grew. My time with the project ended a long time ago, but now the project is releasing. Who knows what the revenue split situation looks like now.

Sound familiar? If you've ever been part of a collaborative creative project, you've probably lived this nightmare. Revenue sharing promises a solution to fairly compensating everyone who contributes to a project's success. But like most good ideas, it's often implemented poorly - leading to disputes, abandoned projects, and broken relationships.

Our mission at City of Gamers is to fix that.

The Problem with Traditional Revenue Splits

The Excel Nightmare

Spreadsheets seem like the obvious solution. They're free, everyone knows how to use them, and you can customize them however you want. But, IT’S A TRAP!

Here's what really happens:

• Stuff gets lost: Files get corrupted, links break, or someone accidentally deletes the wrong row

• People are inconsistent: Adam logs every bathroom break, Barry only tracks "real work"

• Version conflicts happen: Multiple people editing simultaneously in a spreadsheet creates chaos

• Sheets don't easily scale: What works for 3 people becomes unusable with 8+ contributors

• No accountability: Anyone can edit anyone else's data with no audit trail

The bigger your project gets, the more these problems compound. By the time you're ready to distribute revenue, you're spending more time arguing about who did what than actually creating.

The "All or Nothing" Myth

Here's the first misconception that kills revenue sharing before it starts: you don't need to share 100% of revenue for it to be fair.

Most developers don't expect any revenue share. They're used to hourly rates or fixed payments. This creates a massive opportunity - you can offset significant costs by offering even a modest revenue share percentage.

Consider these scenarios:

• Traditional: Pay a developer $5,000 upfront for two months of work

• Revenue share: 50% revenue share to the dev team

• Hybrid: Pay $500 upfront + 10% revenue share with no cap

In the revenue share scenarios, you've reduced upfront costs while giving your devs skin in the game. When the game succeeds, everyone wins.

The "Forever" Misconception

Another myth: revenue sharing has to last forever.

This assumption scares away both project owners (who fear permanent obligations) and contributors (who worry about getting trapped in bad deals). The solution? Revenue tranches - structured sharing that has defined start dates, end dates, and conditions.We’ll talk about these in depth in another article, but consider these basic tranche scenarios:

• Release Tranche: 25% revenue share for the first six months after launch

• Growth Tranche: 15% revenue share for months 7-18

• Maintenance Tranche: 5% revenue share for years 2-3

• DLC Tranche: 100% revenue share for DLC

Tranches give contributors meaningful compensation during defined revenue periods while giving project owners flexbility in the long-term.

Developer Expectations vs. Reality

Here's what most project owners don't realize: developers have low expectations for revenue sharing.

In our conversations with dozens of indie developers, the most common response to "What revenue share would you expect?" is "Honestly? None. I'd be happy just to get paid on time."

This expectation gap is your opportunity. Offering any revenue share - even 5-10% - positions you as more generous than 90% of project owners. You're not competing against generous revenue splits; you're competing against late payments and scope creep.

What Revenue Sharing Actually Is

Beyond the Money

Revenue sharing isn't just about distributing profits. It's about:

• Recognition: Acknowledging that everyone's contribution matters

• Fairness: Ensuring compensation reflects actual value created

• Sustainability: Building relationships that enable future collaboration

• Alignment: Making sure everyone benefits from project success

When done right, revenue sharing transforms collaborators from hired guns into invested partners. They care about the project's long-term success because their own success depends on it.

Industry Context

Revenue sharing isn't new - it's how the entertainment industry has operated for decades:

• Music: Songwriters, producers, and performers all receive royalties

• Film: Actors, directors, and writers negotiate profit participation

• Publishing: Authors receive advance + royalty structures

• Software: Open source contributors often share in commercial success

Game development is actually behind other creative industries in implementing fair revenue sharing. We're still stuck in the "work-for-hire" mentality while other creative fields have moved to partnership models.

Why It Matters Now

The indie game development landscape has changed dramatically:

• Lower barriers to entry: Tools are cheaper and more accessible

• Influx of developers: Massive layoffs mean developers are empowered to go solo

• Direct distribution: Platforms like Steam and itch.io eliminate gatekeepers

• Remote collaboration: Teams can work together from anywhere

• Flexible careers: Many developers work on multiple projects simultaneously

These changes make traditional employment models less relevant. Revenue sharing enables the flexible, project-based collaboration that modern indie development demands.

City of Gamers' Approach to Fair Revenue Sharing

At City of Gamers, we've learned through experience what works and what doesn't. Our approach balances three critical factors that traditional models ignore.

The Three-Factor CoG Model

1. Time Spent

• Automatically tracked hours (no manual logging)

• Includes active work time, not just "billable" hours

• Accounts for research, planning, and revision time

2. Number of Tasks Completed

• Measurable deliverables with clear completion criteria

• Weights different types of tasks appropriately

• Rewards efficiency without penalizing quality

3. Subjective Difficulty

• Difficulty ratings set by project managers

• Agreed upon by every team member at the start of collaboration

• Accounts for learning curves and technical complexity

Transparency from Day One

The worst revenue sharing disputes happen when expectations aren't clear upfront. Our system eliminates surprises:

• Clear contribution tracking: Everyone can see their own and others' contributions in real-time

• Agreed-upon weights: Difficulty multipliers are team decisions, not unilateral judgments

• Regular updates: Contributors receive weekly summaries of their accumulated contributions

• Open calculations: The revenue split formula is transparent and unchangeable

Real-Time Tracking

No more "What did I work on three weeks ago?" Our platform automatically captures:

• Active work sessions: Time spent in development tools and platforms

• Task completion: Integration with project management tools

• Communication: Time spent in project-related discussions and meetings

• Revisions: Multiple iterations on the same deliverable

Scalable System

Our model works whether you have 2 contributors or 20:

• Role-based defaults: Different contribution types have appropriate weightings

• Flexible hierarchies: Senior contributors can have different base rates

• Subproject tracking: Large projects can be broken into manageable chunks

• Cross-project skills: Contributors build reputation across multiple projects

CoG Model FAQ

"But difficulty is subjective! How can that be fair?"

This is exactly the point. Every project is different. A "simple" UI task might be trivial for an experienced designer but incredibly difficult for a programmer learning design. A "basic" physics implementation might be routine for a senior developer but represent weeks of learning for a junior contributor.

The subjectivity isn't a bug - it's a feature. Your team knows their project, their constraints, and their individual skill levels better than any algorithm could. The key is making those subjective decisions transparent and agreed-upon upfront.

"What if task complexity changes during development?"

This happens on every project. You start with big, architectural tasks ("Build the combat system") and later break them into granular pieces ("Adjust sword swing animation timing"). Or vice versa - small tasks get combined into larger systems as you realize they're interconnected.

This is where the triangle model shows its strength. When task granularity changes:

• Time tracking adapts: More granular tasks = more time entries, but total time remains accurate

• Difficulty balances: Many small tasks with low difficulty ≈ Few large tasks with high difficulty

• Completion counts adjust: The system naturally accounts for different task structures

Like rock-paper-scissors, each factor keeps the others in check. If someone games the task count by breaking everything into tiny pieces, the difficulty ratings stay low and time investment reflects the actual work done.

"Why three factors? Isn't that overly complicated?"

Think about classic game balance: mage-tank-ranger, or rock-paper-scissors. Triads create stability that you can't get with simpler systems.

With just time tracking: Fast workers get penalized, research and thinking time get ignored With just task completion: People create artificial tasks or rush through quality work With just difficulty rating: Complex work gets overvalued while grunt work gets ignored

The three-factor triangle prevents gaming the system:

• Can't inflate time without completing tasks or proving difficulty

• Can't create fake tasks without spending real time on appropriately difficult work

• Can't claim everything is "super difficult" without the time and completion to back it up

This isn't complexity for its own sake - it's the minimum viable complexity needed for fairness.

Revenue Sharing vs. Traditional Payment Models

Understanding when to use revenue sharing requires comparing it to alternatives:

Hourly/Fixed Rate

Pros: Predictable costs, immediate payment, simple accounting Cons: No upside potential, expensive for long projects, misaligned incentives

Best for: Short-term projects, well-defined scope, contributors who need immediate income

Equity

Pros: Maximum alignment, long-term commitment, shared ownership Cons: Complex legal structures, dilution concerns, difficult to value

Best for: Co-founder relationships, long-term partnerships, contributors making substantial commitments

Revenue Sharing

Pros: Shared risk and reward, flexible commitment levels, performance alignment Cons: Uncertain payments, complex tracking, requires trust, can have complex legal agreements

Best for: Project-based collaboration, experimental ventures, building long-term relationships

Hybrid Models

The most successful projects often combine approaches:

Base + Revenue Share: Small upfront payment + percentage of revenue

• Reduces contributor risk while maintaining upside

• Lower upfront costs than pure hourly rates

• Creates commitment without full equity complexity

Milestone + Revenue Share: Payments tied to project milestones + revenue participation

• Ensures progress while building toward shared success

• Good for longer projects with uncertain timelines

• Balances contributor security with project owner flexibility

Getting Started with Revenue Sharing

Start Small

Your first revenue sharing project shouldn't be your magnum opus. Start with:

• Limited scope: 3-6 month projects with clear deliverables

• Small teams: 2-4 contributors maximum

• Conservative percentages: 10-25% total revenue share

• Simple structures: Single tranche with clear start/end dates

Success builds trust. Once your team sees revenue sharing work on a small project, they'll be excited to collaborate on bigger ventures.

Set Clear Expectations

Document everything before work begins:

Revenue Model: How will revenue be generated and when? Share Percentage: What percentage goes to contributors vs. project owner? Tracking Method: How will contributions be measured and recorded? Payment Schedule: When and how will revenue shares be distributed? Duration: How long will the revenue sharing arrangement last?

Use Proper Tools

Spreadsheets fail because they're not designed for collaborative, dynamic tracking. You need:

• Automated time tracking: Integration with development tools

• Task management: Clear deliverable definitions and completion tracking

• Real-time reporting: Everyone can see current contribution standings

• Payment integration: Automated distribution when revenue thresholds are met

• Audit trails: Complete history of all changes and decisions

Build Trust

Revenue sharing requires higher trust than traditional payment models. Build it through:

Transparency: Open books, clear communication, regular updates Reliability: Consistent payments, met deadlines, honest communication Fairness: Equal treatment, reasonable expectations, conflict resolution Success: Delivered projects, shared wins, growing relationships

Common Pitfalls and How to Avoid Them

Over-Complicated Structures

The Problem: Multiple tranches, complex formulas, conditional clauses The Solution: Start simple. Add complexity only when the basic model proves successful.

Unrealistic Revenue Projections

The Problem: "This game will definitely make $100K in the first month" The Solution: Conservative estimates. Plan for revenue sharing to be a bonus, not primary compensation.

Poor Communication

The Problem: Assumptions about contribution value, unclear expectations The Solution: Regular check-ins. Weekly contribution summaries. Monthly team meetings.

Inadequate Documentation

The Problem: Handshake agreements, verbal commitments, unclear terms The Solution: Written agreements. Platform-enforced rules. Legal review for larger projects.

Ignoring Legal Considerations

The Problem: Tax implications, contractor vs. employee classification, international payments The Solution: Consult with accountants and lawyers. Use platforms that handle compliance.

The Future of Fair Compensation

Revenue sharing represents more than just an alternative payment model - it's a fundamental shift toward more equitable creative collaboration.

Traditional game development often resembles factory work: defined roles, fixed compensation, clear hierarchies. But creative work doesn't fit factory models. Ideas come from anywhere, contributions vary wildly, and success depends on collective creativity rather than individual productivity.

Revenue sharing acknowledges this reality. It says "we're all in this together" and backs that up with shared financial outcomes.

As remote work becomes standard and project-based collaboration increases, revenue sharing will become the norm rather than the exception. The question isn't whether your next project will use revenue sharing - it's whether you'll implement it fairly and effectively.

Ready to Get Started?

Revenue sharing works when it's implemented thoughtfully, tracked accurately, and communicated clearly. It fails when teams rely on spreadsheets, handshake agreements, and wishful thinking.

Our app Royaltea automates the entire process, from contribution tracking to payment distribution. Our contribution tracking model balances time, tasks, and difficulty to ensure everyone receives fair compensation based on their actual contributions.

No more lost spreadsheets. No more tracking disputes. No more wondering who did what.

Ready to implement fair revenue sharing that actually works?

Start Your Free Trial →

See how our platform can transform your next collaborative project from a tracking nightmare into a transparent, fair partnership where everyone benefits from shared success.

Questions about revenue sharing? Join our Discord community where hundreds of indie developers share experiences, strategies, and success stories about collaborative game development.