Why we built native first

The web-first assumption we nearly made

Like most founders, we started with the assumption that every SaaS tool should launch with a web interface. It made sense on paper. Web is universal. Web is faster to ship. Web is the default.

We had a prototype of Shpd as a traditional feedback platform: users get an email link, click through to a web page, vote on a feature request board. Done. Clean. Proven. Canny had done this for years.

But we weren't building for enterprises managing a single product. We were building for mobile studios, the kind of companies managing five, ten, sometimes twenty iOS and Android apps. One of our earliest customers ran eleven apps in the health and fitness category. Another had eight games. When we asked them to walk through the voting flow, they all said the same thing: most of their users would never follow the link.

Not because the users didn't care about features. They just weren't going to leave the app they were using to vote on a different website.

The shift: meeting users where they actually are

That October conversation became the inflection point. Instead of asking app users to migrate to a web page, what if the voting happened inside the app itself? What if your users could see a feature request board, vote on it, and read comments without ever leaving?

It meant learning Kotlin. It meant maintaining two SDKs in parallel. It meant a slower launch and more engineering hours. But it also meant something else: our users would actually use it.

We built the native iOS SDK as a Swift Package. Android got a Kotlin library. Both could be dropped into your codebase in minutes. Both handled the voting interface, the comment threads, the analytics - all native to the platform. No WebView tricks. No 'app-like experience on the web'. Real mobile.

The decision cascaded. If voting happens inside the app, then we needed a way for the same user to vote across your entire portfolio. That's how Passport - our cross-app voter identity system - was born. Your user votes on Feature A in App One, then later votes on Feature B in App Two. We track that as the same person. Not by email. By a persistent identity that lives on the device.

What native unlocked that web couldn't

Once we had the SDKs in place, native capabilities opened up. We could send a push notification the moment a feature ships. Not an email. A notification, right there, telling voters their requested feature is live. That happened in February. We watched notification open rates. Ninety-two percent of voters opened them.

The voting board itself became something else. Because it lives inside the app, it can be search-indexed by Google. Your public roadmap is on the open web. SEO works. Voters can find your roadmap in a search engine and land directly inside your app when they download it.

None of that was accidental. Each of these features was only possible because we chose to build SDKs instead of a web form. Web-first would have given us a faster launch and simpler code. Native-first gave us a tool that studios actually wanted to integrate into their products.

The honest reason we didn't cut corners

I should say what the real constraint was. We could have shipped a web-only MVP in six weeks. We could have added SDKs later, 'if people asked for them'. That's the startup playbook. Ship fast. Get feedback. Iterate.

The problem was, if we shipped web-only, nobody would ask for SDKs. They'd ask for it to be easier to use, which it already would be from a web link. We'd be building a slightly better Canny, and we'd be betting that 'slightly better' would be enough to pull studios away from their existing tool. It wouldn't.

The native bet meant we had to get it right before launch. No 'let's see what they want and build it later'. The entire foundation had to work. That meant more time, more engineering, and a later go-to-market date. But it also meant that when we launched, we were solving a real problem that existed nowhere else.

Who this mattered for most

The studios that found us earliest were, almost always, the ones running multiple apps. A game developer with four titles in the App Store. A health app company managing wellness, tracking, and coaching products separately. A utilities studio with five niche apps across different categories.

These teams had been trying to use feedback tools built for single-product companies. Canny worked fine for one app. But managing voter feedback across four apps, making sure the same user isn't voting twice, keeping the roadmaps separate or unified - those tools weren't designed for that shape of problem.

When we announced Passport, our cross-app identity system, one founder wrote back: 'This is the first time I've seen a tool that actually understands how we work.' That email landed in my inbox during a meeting, and I had to step out to read it twice.

The launch decision in hindsight

In December 2024, Canny announced a price increase that pushed a lot of studios our way. We were ready because we'd made the hard choice months earlier. We weren't trying to copy what Canny did with a slightly different interface. We had built something fundamentally different: a voting platform that lived inside apps, not outside them.

Would native-first have been the right choice for every kind of company? No. For a B2B SaaS tool serving enterprises managing one product, web-first makes total sense. For studios managing portfolios of mobile apps, it was the only choice that mattered.

Looking back, the real insight wasn't about technology. It was about understanding who you're building for deeply enough that you're willing to take the slower, harder path if it's the right one for them. We chose native not because native is inherently better. We chose it because the studios we were building for lived in native. That's where the voting should happen.