— Enten Journal —
How to Hire a Developer or CTO with Revenue Sharing (Instead of Equity)
You've found the engineer you want. Senior, sharp, exactly the person to build the thing — and out of your budget at full cash rate. The standard advice is to close the gap with equity. But equity is a heavy instrument: it dilutes you, it sits on your cap table forever, it needs approvals and paperwork, and it only pays your new hire on an exit that may be years away, if it happens at all.
There's a lighter option that's become far more common for exactly this situation: hire them on a reduced cash rate plus a share of the revenue their work helps generate. Here's how it works, how to size it, and when you shouldn't.
Why do startups use revenue sharing to hire developers?
Because it solves the exact problem equity is a clumsy fit for: paying fairly for work whose value is real but not yet proven, without giving away ownership or draining runway.
A revenue share lets a smaller company put together a competitive offer that a larger employer can't easily match — below-market cash now, plus genuine, potentially uncapped upside tied to the product actually succeeding. For a confident senior engineer, that upside is attractive; for you, it converts a fixed cost you can't afford into a variable one that only grows when the product does.
Crucially, it keeps the incentive in the right place. A developer on a fixed day rate optimises for hours billed or tickets closed. A developer with a share of product revenue optimises for the product making money — which is what you actually want them doing.
How does a developer revenue share actually work?
Three levers, agreed up front:
- A reduced day rate (or salary). You pay less than full market rate in cash — the discount is what the revenue share is buying.
- A percentage of product revenue. The developer receives an agreed share of the revenue their work helps generate, usually from a specific, named product or product line.
- A time-limited term. The share runs for a defined period — commonly 24 months from launch — not forever.
So instead of "£600/day, indefinitely," the offer becomes something like "£300/day plus 2% of the product's revenue for 24 months." The engineer trades some certainty now for a shot at meaningful upside later; you protect cash and only pay more if the product performs.
How much revenue share should you offer a developer?
For technical contributors, revenue shares typically land in the range of 1–5% of the relevant product revenue, depending on how central their contribution is, how much cash they're deferring, and how much revenue you realistically expect.
The clean way to size it is to work back from the cash you're deferring:
Worked example. You'd normally pay a senior developer £600/day. Instead you offer £300/day plus 2% of product revenue for 24 months. If the product generates £500,000 in its first year, the developer earns their reduced rate plus £10,000 in revenue share. If it only makes £50,000, you've been protected from overpaying for a product that didn't land. If it takes off and makes £1.5M, they earn £30,000 — funded entirely by revenue you wouldn't have had without them.
That last line is the point: a well-structured share pays out from the upside it helped create, not out of scarce runway.
Cash vs equity vs revenue share, for a developer hire
| Full cash rate | Equity | Reduced cash + revenue share | |
|---|---|---|---|
| Upfront cost to you | High | Low | Low–medium |
| Dilutes ownership | No | Yes | No |
| On your cap table | No | Permanently | No |
| When the hire is paid | Now | On exit (maybe never) | As revenue arrives |
| Incentive to grow revenue | Weak | Long-term, indirect | Direct, near-term |
| Speed to agree | Fast | Slow | Fast |
| Reversible / time-boxed | n/a | Hard | Built in |
What counts as "revenue"? Define it before you sign
The single most common source of revenue-share disputes is disagreement over what "revenue" means — and with a developer it's usually straightforward to get right if you're deliberate about it.
Define the share against gross revenue from a specific, named product or service, and exclude VAT/sales tax, refunds, and inter-company transfers. Decide up front whether the base is all revenue from that product or only revenue above a threshold, and what happens if the developer leaves partway through the term. Vagueness here — "a share of the revenue" with no named stream — is the mistake that turns a good arrangement into an argument later.
When is revenue sharing the wrong way to hire a developer?
Be honest with yourself before you offer it. A revenue share is the wrong tool when:
- You're pre-revenue with no clear line to market. If there's no reasonable estimate of when meaningful revenue starts, a share of revenue offers the developer nothing concrete — equity (which captures long-term value regardless of timing) or a straight fee is a better fit.
- The hire is genuinely foundational. If you're bringing on a technical co-founder building long-term enterprise value across the whole company, that's an equity conversation, not a product-revenue share.
- You can't cleanly attribute revenue to their work. If the product's revenue is tangled up with everything else and you can't define a fair base, the arrangement will strain.
- You can't or won't report honestly. A revenue share depends on the developer trusting your numbers. If you can't share revenue data or grant audit rights, trust erodes fast.
A UK note: IR35 and tax
If you're engaging an individual developer on an ongoing basis, assess IR35 / off-payroll working status carefully — a long-term, closely-directed engagement can fall inside IR35, in which case you may need to deduct income tax and National Insurance from payments, including the revenue-share element. Revenue-share payments are generally taxable income for the recipient, and VAT usually applies where the developer is VAT-registered. Structure the arrangement as payment for services, not as something resembling an investment return.
This is general information, not legal or tax advice — take professional advice on your specific arrangement.
Getting started
If you want to hire someone brilliant you can't quite afford, a revenue share is often the cleanest way to bridge the gap — competitive for them, cap-table-safe for you, and aligned by design.
Enten provides the legal frameworks, templates, and platform to structure and run a developer revenue share end to end. Model your first deal, or download the complete guide to revenue sharing for benchmark percentages, worked examples, and the clauses that keep these arrangements clean.