How to Structure a Revenue Share Deal for an AI Project
How to structure a revenue share deal instead of a flat fee for an AI project: percentage, cap, duration, and the attribution problem nobody mentions.
How to Structure a Revenue Share Deal for an AI Project
A revenue share deal trades a lower or zero upfront fee for a percentage of what the thing you build actually earns, usually because the client is cash-poor, genuinely believes in the upside, or you both want your incentives pointed the same direction. It works when four things are nailed down before you write a line of code: the percentage, the cap, the duration, and how revenue actually gets measured. Skip any one of those and the deal turns into a slow-motion argument.
When it makes sense, and when it does not
Revenue share fits a client with real distribution and a plausible revenue model but limited cash today, where you genuinely believe the thing will make money and are willing to be paid on a delay for a bigger total number. It does not fit a client who wants free work with an unlikely payout attached, or a product where revenue will be indirect and hard to attribute, like an internal tool or a lead-gen funnel with no direct sales. If either of those describes your situation, a flat fee or milestone structure is the honest answer, and our breakdown of payment milestones for an AI project covers that alternative in detail.
The four terms that actually need defining
Term | What to nail down | What happens if you don't |
|---|---|---|
Percentage | A specific number, tied to gross or net revenue, stated explicitly | “A share of revenue” with no number is not an agreement, it is a disagreement waiting to happen at the first payout |
Cap | A total dollar amount or time limit after which the share ends | An open-ended percentage on a product that succeeds beyond expectations becomes a fight neither side saw coming |
Duration | How long the share runs even if the cap is never hit (often 12 to 36 months) | You are owed a share forever on work you did once, with no natural end, which most clients will eventually resist paying |
Measurement | Exactly what counts as revenue, who can audit it, and how often it is reported | You are trusting the client's word with no way to verify it, which is the single most common source of revenue-share disputes |
The attribution problem nobody mentions upfront
If the product you built is one part of a larger business, revenue attribution gets genuinely hard, not just contentious. A booking app you built might drive some percentage of a business's total bookings, but the business also has walk-ins, phone bookings, and referrals that have nothing to do with your app. Agree in writing on what counts as attributable revenue before launch, not after the first disputed invoice, and consider a simpler proxy (like a flat fee per transaction the app processes) instead of a percentage of total business revenue when attribution is genuinely ambiguous.
A minimal structure that avoids most disputes
A specific percentage of gross revenue directly processed through the thing you built, not the client's total business revenue.
A cap: either a total dollar amount, or an automatic conversion to a flat licensing fee after 24 months, whichever comes first.
A reporting cadence in the contract itself: monthly revenue reports within 15 days of month end, with a right to request a transaction-level export twice a year.
A floor payment covering your bare costs, even if revenue share is the main compensation, so a slow launch does not mean months of unpaid work.
How this compares to the alternatives
Revenue share is one of three real ways to get paid on a delay or on the upside instead of a flat fee up front. If the client is offering ownership instead of a percentage of revenue, that is a fundamentally different risk profile, covered in getting paid in equity instead of cash for AI freelance work. And if you are trying to work out what a fair number even looks like before structuring any of this, how much a two-person agency should charge for an AI-built MVP is the right starting point for the baseline flat-fee number to compare a revenue share offer against.
FAQ
What percentage is typical?
There is no universal number, but deals that also include some upfront payment tend to land lower (5 to 15 percent) than pure sweat-equity-style arrangements with zero cash upfront (which can run 20 percent or higher), reflecting the difference in risk you are actually carrying.
Should I ask for read access to their payment processor?
It is a reasonable ask and far better than trusting self-reported numbers with no way to check them. Many clients will agree to limited, revenue-only read access rather than handing over full financial visibility.
What if the client wants revenue share on a product that later pivots?
Define “the product” narrowly in the contract, tied to what you actually built, not whatever the business becomes. A pivot to an unrelated product should end your revenue share on the original scope, and the contract should say so explicitly rather than leaving it to interpretation later.
For the rest of the monetization playbook, see our AI monetization strategies hub.
How did this land?
About the author
Growth & SEO Lead
Manuele covers distribution: SEO, content strategy, and how AI-built products find their first thousand users. He tests everything he recommends.
