Revenue Share as Strategy: Signalling Confidence to Developers

Revenue Share as Strategy: Signalling Confidence to Developers

HubSpot charges 0%. Atlassian 0% on first $1M. Shopify 15%. Revenue share isn't a financial decision: it's a developer acquisition strategy.

Three platforms. Three different revenue share models. HubSpot takes nothing. Atlassian takes nothing on the first million in lifetime Forge revenue, then a modest 16–17%. Shopify takes nothing on the first million in lifetime earnings, then 15%. None of these numbers were set by a finance team optimising for margin. They were set by people who understood that the percentage printed in a partner agreement is not primarily a revenue figure. It is a signal.

What those numbers signal, to the developer deciding whether to invest a year of engineering time in your platform, is whether you view them as a customer or as a source of extraction. Get that signal wrong, and the developer doesn't file a complaint. They close the tab and build on someone else's platform instead.

The 0% model is not charity

HubSpot's App Partner Program charges zero percent revenue share. No listing fee. No commission. The result, after years of that policy, is more than 2,000 integrations in the marketplace, a median partner revenue growth rate expected to hit 43.8% in 2025, and an ecosystem that IDC projects will exceed $7 billion by 2028 for companies with over 200 employees. The longer-term projection reaches $36 billion.

None of that value shows up in HubSpot's own income statement as marketplace revenue. That was the point. HubSpot decided early that the return on an open ecosystem was worth more than the margin from a closed one, and it structured its revenue share accordingly.

The platforms with the strongest flywheels all converge on the same logic: 0% revenue share is not a discount. It is developer acquisition cost, budgeted the same way a sales organisation budgets for customer acquisition. The question is not "can we afford 0%?" but "what is the cost per developer acquired, and what is their lifetime value?" When the math is run that way, the answer is usually obvious. The developer who builds a niche integration and brings thousands of new customers into your orbit is worth far more than 30% of their first year's revenue.

The rate matters less than what it signals

The common mistake in thinking about revenue share is to focus on the percentage. The more important variable is what the percentage communicates about the relationship between the platform and its developers.

Apple charges 30%, reduced to 15% after year one. That rate has produced worse developer relations than Shopify's 15% or Atlassian's 16–17%, despite being numerically comparable. The difference isn't the math. Apple's governance decisions have made the same point: fighting external purchase links in court, charging 27% on external link sales after a court required it to allow them, responding to EU antitrust fines with new fees. Each decision has consistently signalled that the App Store is a toll gate. Developers received that signal and interpreted it correctly.

Shopify's 15% sits in similar territory. But Shopify's policy has always been explained in terms the ecosystem can accept: lower rates help developers reach viability, which produces more apps, which serves merchants, which grows the platform. That narrative is coherent and has held for years. Developers who understand it are making multi-year commitments on the back of it.

The rate that developers can plan around is always preferable to a better rate they can't trust.

What happens when the rules change

In June 2025, Shopify changed its revenue share terms in a way that made this principle concrete.

The original policy gave developers 0% on the first $1 million in annual App Store earnings, with the counter resetting each January 1st. A developer earning $800,000 a year paid nothing, indefinitely. The new policy, effective June 16, 2025, changed that to a lifetime cap: developers keep the first $1 million in lifetime earnings commission-free, then pay 15% on all revenue thereafter. A developer earning $1.5 million annually went from paying $75,000 per year in commissions to $225,000.

The backlash was pointed. The criticism was not about the 15% rate, which hadn't changed. It was about the fact that rules built into multi-year financial models had changed retroactively, on a short timeline. Developers had built team budgets, event spending, and growth plans around a known commission structure. That structure changed with six weeks' notice.

Shopify's VP of Product argued the annual reset had only benefited a few hundred developers, which may be accurate. But those are precisely the developers most central to the flywheel's health. A policy that costs a platform's most successful ecosystem participants hundreds of thousands of dollars per year without proportionate warning is a signal. What it signals is that the rules are contingent, not durable.

The Shopify example is not a story about a bad platform. The 15% rate is genuinely reasonable. It is a story about the asymmetric cost of breaking trust versus building it. Years of goodwill accumulated through a clear, predictable policy were spent in a single announcement cycle.

Atlassian's carrot-and-stick

Atlassian has taken a more deliberately strategic approach to revenue share design, using it explicitly as a migration lever and not just a developer acquisition tool.

Beginning in 2026, Atlassian's revenue share rates diverge sharply based on which platform a developer builds on. Apps built on Connect (the older, externally-hosted framework) face rates rising from 15% to 20% in April 2026, then to 25% later in the year. Apps built on Forge (Atlassian's hosted execution environment) face rates rising from 15% to only 16%, then 17%. Both categories also receive 0% on the first $1 million in lifetime Forge revenue, an explicit incentive for Connect developers to migrate.

The signal is unmistakeable: staying on Connect becomes progressively more expensive. Building on Forge becomes progressively more advantageous. Atlassian is using its revenue share structure to steer its developer ecosystem toward the infrastructure it wants them on: the one that gives it more control over security, compliance, and data residency, which its enterprise customers require.

This is revenue share as governance, not just as economics. The rates are set not to maximise take from any individual developer but to move the ecosystem in a direction that serves the platform's long-term interests. And it's working: Atlassian extended the rate increases by three months in response to developer feedback, accelerated the 0% incentive for Runs on Atlassian apps by three months in the other direction, and published the complete timeline of changes well in advance. The divergence is deliberate, the reasoning is transparent, and developers have enough runway to make rational migration decisions.

That combination is what distinguishes governance from extraction: clear rates, a published timeline, a logical rationale, and economic incentive pointing in the right direction.

When to move from 0% to tiered

The question for platforms earlier in their ecosystem journey is not whether to charge a revenue share. It is when, and how to announce the transition.

The economics of 0% revenue share make sense as long as developer acquisition is the primary goal. Once you have an attach rate north of 50%, thousands of listed apps, and developers whose entire businesses are built on your marketplace, the calculus shifts. The platform has earned the right to take a share, because the share it is taking is a fraction of the distribution value it is providing.

The transition is defensible when announced well in advance, explained with a rationale developers can accept, and set at a rate they'd describe as fair given the platform's demonstrated value. Atlassian's approach is the model: incentive and penalty, clearly telegraphed, with migration tools provided and timelines published.

What's not defensible is changing the rules retroactively and on short notice. Even if the rate is reasonable, the manner of change sends a signal that outlasts the backlash.

The rate is a mirror

Every revenue share decision a platform makes is a mirror held up to its ecosystem strategy. A 0% model says: we are building this together, and your success is our success. A 30% model extracted from the first dollar says: we are a toll gate, and your access to our distribution is a service we're charging for. A tiered model, clearly explained and gradually applied, says: we have earned a share of the value we're helping create, and here is how we're taking it.

Developers read these signals. They are running businesses on the back of your platform's decisions, and they remember the precedents those decisions set. The platform that treats its revenue share as a strategic communication, about confidence in the ecosystem and the relationship it wants with developers, earns a kind of trust that is very difficult for a competitor to replicate. The platform that treats it as a margin line item earns something else entirely.

The $4 economy only exists because Salesforce spent twenty years making developers believe it was worth their time to build on the platform. Revenue share was one of the earliest and most legible signals in that relationship. Every number in a partner agreement is a sentence in an ongoing conversation. The question is whether the platform knows what it is saying.