Why we built Shpd with native Kotlin instead of a web form

The moment we realised web forms weren't enough

When we started Shpd, the market already had feature-voting tools. Canny had proved the concept worked. But every one of them operated the same way: you embed a web widget or send users to a separate page. It's fine for a B2B dashboard tool. It's friction for a consumer app.

That studio founder wasn't alone. As we talked to more app studios, we heard the same thing. Users would vote once, maybe twice. Then they'd stop. Not because they didn't care about features. Because leaving the app to do it felt broken. And if you're running five apps, asking users to vote on five different web pages? They won't.

We realised we weren't building for Canny's audience. Canny sells to SaaS startups with one product. We were talking to studios with portfolios. The mechanics were completely different.

Mobile-first meant building for real phones

The decision to ship native SDKs wasn't trendy. It was practical. If your entire audience lives in iOS and Android apps, giving them a web form is like handing someone a phone number when they asked for a text.

We built a native iOS Swift Package first. It felt right immediately. Users could vote without leaving the app. No loading spinners. No web browser refresh. Just instant, native interaction. The vote counts updated in real time. Push notifications arrived the moment a feature shipped.

Android had to follow the same way. We shipped the Kotlin SDK because that's what Android developers expect to integrate. Not a WebView wrapper. Not a web iframe. An actual library that feels like part of the app.

The trade-off was real. Building two SDKs instead of one web widget means more code to maintain, more platforms to test, more complexity. But it meant something else too: your users don't have to think about voting. They just vote.

The problem with voters scattered across ten apps

Here's where it got interesting. Once studios started using both SDKs, they asked: 'Why does my voter have to create an account in every app?'

Most feature-voting tools treat each app as separate. One voter, five apps, five logins. That's how web-based tools work. Each one is its own silo.

We built Passport. It's a cross-app voter identity system. One person votes once, across your entire portfolio. They don't log in again. When they vote on a feature in your photography app, they're the same voter as when they vote in your music app.

It sounds small. It's actually the difference between a tool that feels like an afterthought and one that feels native to how studios operate. One voter seeing their impact across five apps is more invested than five separate voters on five isolated platforms.

Honesty about billing for mobile

We made a choice that cost us money. Every payment goes through Stripe, not the App Store.

Why? Because the App Store takes 30 percent. Most SaaS tools hide that cost in their pricing. We didn't want to. If you're a small studio running Shpd on a per-seat budget, you deserve to know that your cost is your cost. No hidden percentage going to Apple or Google.

This matters more than it sounds. When studios were evaluating us against Canny after their December price increase, some were looking at the maths hard. They wanted to know exactly what they were paying. Native SDKs plus transparent billing meant we could give them an honest answer.

What the future looks like when you build for studios

Building native SDKs opened doors that web-only tools can't reach. Push notifications when features ship. Voter retention data overlaid on your feature board. Analytics that actually matter to your product roadmap, not just vanity metrics.

But the deeper shift was about respect. Respect for the fact that mobile app studios are a different creature than single-product SaaS companies. They're juggling iOS, Android, multiple app stores, multiple user bases, cross-portfolio user experience. The tools they use should reflect that reality, not force them into a single-product model.

We're still a small team. We're not trying to be everything for everyone. But what we've built, we've built specifically for studios. Native all the way down. That's not a marketing angle. That's how we work.