App developer contracts that pay via revenue share instead of flat fees look attractive — until the first royalty statement arrives. The product ships, revenue flows in, and the developer discovers that 'net revenue' has been defined in the contract to exclude almost everything. Before you sign a rev-share app deal, three things matter more than the headline percentage: the exact definition of the revenue being shared, who owns the code if the deal ends, and whether you can actually see the numbers that drive your cheque.
What is a Revenue Share?
An app developer revenue-share contract is a development agreement where compensation — in whole or part — is calculated as a percentage of revenue generated by the app after launch. Revenue share deals are common in indie gaming, consumer mobile apps and early-stage SaaS, and they sit at the intersection of work-for-hire copyright rules (17 U.S.C. §101), standard commercial contract law, and (increasingly) App Store distribution rules from Apple and Google which affect how 'revenue' is calculated after platform fees.
Red flags to watch for
Each subtraction shrinks the pool. A 20% revenue share on 'net net net' revenue can easily be 5% of gross. Model the numbers before agreeing.
Without audit rights you rely on the client's math. Industry standard is annual audit rights with 30 days' notice, with client paying costs if discrepancy exceeds 5%.
Assigning IP upfront means if the client stops paying or the product stalls, your code and design are gone. IP should assign only on full payment, or revert if the deal is breached.
A 3-year rev-share cap on a 10-year product life lets the client harvest the tail. Aim for rev share that lasts as long as the product earns material revenue.
Bundling with other products makes 'the app's revenue' unknowable. Contract should require fair allocation or consent.
A broad non-compete can end your career as a specialist. California has largely banned them (Cal. Bus. & Prof. Code §16600). Scope and duration must be reasonable.
For indie developers, portfolio credit is part of compensation. Losing the right to say you built the app damages future revenue.
Your legal rights
US app developer contracts are primarily governed by state contract law (with California, New York, Washington and Delaware being common choices of law for tech deals). Under 17 U.S.C. §101, source code is copyrighted by the author unless a written agreement assigns it or it qualifies as 'work made for hire' — which for commissioned software requires a signed written agreement and a qualifying category. The Defend Trade Secrets Act (18 U.S.C. §1836) provides federal protection for trade secrets including unreleased code. California, Washington and a growing number of states restrict employee non-competes (Cal. Bus. & Prof. Code §16600, RCW 49.62), and similar rules increasingly apply to independent-contractor non-competes. Revenue-share disputes routinely involve common-law duties of good faith and fair dealing, which most states recognise as implied in every contract.
Questions to ask before you sign
- 1How exactly is 'revenue' or 'net revenue' defined — what is subtracted, in what order?
- 2What audit rights do I have and how often can I exercise them?
- 3When does IP ownership transfer — at signing, at launch, or on full payment?
- 4If the product is discontinued or sold, what happens to my revenue share?
- 5Is the revenue share perpetual, or does it expire?
- 6Can the client bundle this app with other products, and if so, how is my share calculated?
- 7Is there a non-compete or non-solicit, and is it limited in scope and duration?
- 8What happens to the code and my credits if the client fails to pay or breaches the agreement?
Disclaimer: This guide is for educational purposes only and does not constitute legal advice. Contract law varies by jurisdiction and individual circumstances. Always consult a qualified legal professional before making decisions based on this information.