Why we got the Solo free tier voter cap wrong

The assumption we baked in

When we designed Shpd's Solo free tier, we thought like SaaS companies typically do: cap something measurable, watch adoption, convert the paying segment. We chose 100 voters per month. It felt generous for a single app. It felt like enough to 'kick the tyres.'

The problem was that 100 voters per month isn't actually a bottleneck for most mobile studios testing us out. A founder with one app, running Shpd without the native SDK, relying on a web form or a link they drop in a forum or Discord, might accumulate 20 to 40 votes in a month. Maybe 60 if they're pushing it to users actively.

The real bottleneck wasn't the voter cap. It was the SDK. Our Studio tier (£19/month) unlocks native iOS and Android integrations. That's where the product becomes what Shpd actually is. A founder stuck on the free tier can never experience that. The cap was a proxy for keeping them out of the real thing.

What we actually heard from people

Once we started paying attention, the feedback wasn't about the number. It was about access. Founders on free said things like: 'I want to try this with my iOS app, but the free tier doesn't have the SDK.' Or: 'We have five apps but you only let me use one on free.'

Those aren't complaints about being rate-limited. They're admissions that the free tier was doing exactly what we designed it to do: keep them away from what makes Shpd different. And in doing that, we were preventing them from ever deciding whether to pay.

A founder who's never integrated the native SDK has no reason to believe a £19 monthly subscription is worth it. They're comparing Shpd to a web form and asking themselves why they'd pay at all. A founder who's spent an afternoon embedding our Swift Package and seen a vote land in their app in real time, in-context, with a push notification firing when the feature ships? That's a different conversation entirely.

The shift we're making

We've decided to rethink what the free tier is for. It's not for containing costs or filtering out 'unserious' users. It's for letting people experience the core product without friction. That means native SDK access on Solo free. It means letting someone try Shpd across two of their apps, not one.

The 100-voter cap stays, but now it's no longer the wall between free and paid. It's just a throttle on scale. A founder can build real integration, ship it to users, gather feedback, and genuinely evaluate whether Shpd moves the needle for them. By the time they hit that cap, they'll either know the answer or they won't care about the limit.

It's a smaller change than it sounds. But it reflects something we got backwards: the job of a free tier isn't to be small. It's to be honest. It should let someone try the real thing, at real scale within reason, and make an informed choice about whether to pay.

Why this matters for studios fleeing other platforms

A lot of founders are coming to Shpd because they were paying for Canny and watched the pricing change in December 2025 make the maths uncomfortable. They're evaluating whether to switch. A free tier with no SDK access, even with a generous voter cap, looks like every other feedback tool. It doesn't show them what makes Shpd built for mobile studios.

By opening the native SDKs on free, we're saying: 'Yes, integrate this properly. See what your users actually do when voting lives inside your app, not on a separate page. Then decide.' That's how a free tier earns trust. And for studios coming from another platform, earning that trust quickly is the whole game.