Why we said no to in-app purchase billing on the SDK side

The moment we realised the economics didn't work

Let's be direct. If we'd built Shpd's billing through StoreKit or Google Play's in-app purchase system, every studio subscribing to Studio, Scale, or Portfolio would pay Apple or Google a 15 to 30 percent cut on top of what they pay us. For a studio running five apps with a few thousand monthly voters, that's real money disappearing from their margin - money they'd almost certainly pass back to us by choosing a cheaper tool or building in-house.

We ran the numbers. A small app studio on our Studio plan (£180 per year) would see Apple or Google take somewhere between £27 and £54 annually. Sounds tiny until you multiply it across three, five, or ten apps. Then it's hundreds of pounds a year in invisible tax on their feature-voting infrastructure.

But there was a second reason we rejected it. Control. If your billing runs through the App Store, Apple owns the relationship. They can change commission rates, suspend your app, or take weeks to approve billing updates. We'd be handing our customers' financial relationship to a third party. That felt wrong for a B2B tool.

What Stripe actually gave us

We switched to Stripe the moment we made that decision, and it changed how we think about our customers' money.

Stripe meant we could bill directly. No commission. No App Store review gates. No waiting for Apple's blessing on a pricing change. When a studio upgrades from Studio to Scale or adds a second app to their dashboard, the change is live within seconds. The economics are clean. What they pay us is what we get.

More importantly, Stripe meant we could be transparent. Our per-seat unit economics are honest. A studio with 2,000 monthly voters on Studio tier pays the same as a studio with 200. No hidden tiers. No 'you've hit a quota, upgrade now.' The SDK counts voters as they come in, and billing scales predictably. Studios can forecast their costs.

We also got something we didn't expect: trust. When we talk to founders about pricing, they don't have to wonder if we're hiding an App Store tax. They can read our pricing page, calculate their cost, and know exactly what they're paying. That honesty matters in B2B. It's the difference between being a vendor and being a partner.

The customers who moved to us because of this

We saw the real impact when Canny announced their December 2025 price change. Studios started looking around. Many of them had been using Canny for years, dealing with in-app purchase billing on the web side and feeling the margin pressure. They wanted out.

One studio with eight apps told us they'd spent £400 the previous year on Canny itself. When they modelled what they'd pay with us, the number was significantly lower, and there was no App Store tax on top. They signed up the same day we showed them the calculator.

These weren't companies trying to save five pounds. They were teams that had spent years inside a feedback-voting platform and understood exactly where their money was going. They valued the transparency. They valued the lack of a middleman taking a cut. And they appreciated that we'd built the SDK native to iOS and Android, so voting happened inside their app, not on a web page their users had to open separately.

That's the thing about saying no to in-app purchase billing. It sounds like a technical decision. It's actually a choice about who we're building for and how we want to work with them.

What this meant for how we built the product

Choosing Stripe rippled through the entire product. We could invest in features that mattered to studios without wondering if they'd trigger App Store review. We built Passport, our cross-app voter identity system, without worrying about billing gates. We added push notifications the moment your feature ships because we didn't need Apple's approval for subscription-related notifications.

The webhooks and API on Scale tier, the AI insights digest and Attribr overlay on Portfolio, the white-label option; none of these would be as straightforward if we were threading everything through in-app purchase billing. The review cycles alone would slow us down.

More than that, it meant we could be a single business with honest pricing, not a company juggling different billing rules for iOS, Android, and web. One dashboard. One invoice. One relationship with the customer.

The choice that doesn't feel like a choice anymore

Looking back, it's obvious. But it wasn't obvious in April. There's real pressure, especially at launch, to do what the established players do. In-app purchase billing is standard for consumer apps. It felt normal.

We chose differently because we're not a consumer app. We're a B2B tool for app studios. Studios care about different things than consumers. They care about margins, transparency, and predictability. They care about their relationship with us being separate from their relationship with Apple or Google.

I think about that customer question a lot. 'Will I have to pay Apple or Google to let my users vote?' The fact that it surprised us is the point. They shouldn't have to. We shouldn't have put them in that position. By the time they asked, we'd already made the right call. But it's nice to be reminded why it mattered.