The moment I realised we'd built something backwards
It was a Thursday morning in September. A product lead at one of our customers, a London studio running eight iOS apps, sent a Slack message: 'John, we just noticed one of our power users voted for the same feature request in three different apps, but we counted them as three separate voters.' That's when it hit me. We'd designed Shpd for this exact problem, but I'd never really explained why it mattered.
The fragmentation trap
Here's the thing about running a portfolio of apps: your voters don't live in silos, but your feedback tools often force them to. A user who loves your habit tracker also uses your calendar app and your note-taking tool. When they request the same feature across all three, traditional feedback platforms count them as three separate votes. Your roadmap looks busier than it actually is. Your analytics lie.
Before Shpd, most studios I talked to had spreadsheets. Not elegant spreadsheets. Messy, manual ones. They'd export voter lists from Canny or UserVoice or whatever web form they'd bolted onto the app store page, then spend Friday afternoons trying to deduplicate them. 'Is this Emma.smith@gmail.com the same person as e.smith@yahoo.com?' Nobody wins at that game.
The real problem isn't confusion, though. It's decision-making. When you can't see that a feature request is genuinely wanted across your entire portfolio, you deprioritise it. You ship something smaller instead. You miss a genuine signal because the signal was fragmented.
What we actually built with Passport
Last spring, we introduced Passport. It's cross-app voter identity built into our native SDKs. A user votes in your habit tracker, and that same identity votes in your calendar app. Not through a web form. Not through a separate dashboard. Through the native vote button inside the app itself. They're the same voter, recognised across your entire studio's portfolio.
The mechanism is simple: when a user votes inside one of your apps that runs Shpd, we issue them a Passport ID. That ID travels with them. When they vote again in a different app from the same studio, we recognise them. We don't ask for an email. We don't ask them to log in. We just know.
One of our customers, a studio with five iOS apps, ran a test. They had 600 votes on a feature request across all five apps. When Passport deduplicated them, the real count was 280 unique voters. That's a 53% difference. The feature was still worth building, but the urgency changed. The roadmap suddenly looked honest.
Why it changes how you think about roadmaps
Accurate voter counts aren't just about vanity metrics. They're about resource allocation. When you know that a requested feature is genuinely wanted by 280 people across your portfolio, not by 600 phantom votes scattered across apps, you can make better decisions faster.
It also changes how you talk to investors and stakeholders. 'We have 600 votes for this feature' sounds different from 'We have 280 unique users across our portfolio asking for this.' The second one is true. The second one is also more useful for planning.
There's a second angle nobody talks about: user experience. When someone requests a feature in one of your apps, they want to know about it when it ships. All of it. Not just the app they voted in. We push a notification the moment a requested feature goes live, across every app where that voter asked for it. They see the same notification once, not six times. They feel heard across the entire studio, not just in one corner of it.
The studios that need this most
We built Shpd for mobile app studios, but Passport itself solves a problem that only exists at a certain scale. If you run one app, it doesn't matter. Passport doesn't add value until you're running three or more. By the time you're running five to eight apps, voter identity fragmentation becomes a real operational headache.
Most of our customers fall into that band. Studios running anything from two apps to thirty. Big enough that cross-app signals matter. Small enough that they're still making decisions as a team, not a committee. Passport lets them see the real shape of what their users want.
We've also seen interest from studios that recently moved away from Canny. Canny is web-first. It's not built for in-app voting; it's a form you embed or link to. That's fine if you run one property. It's friction if you run many. Some of our newer customers chose Shpd specifically because we built native iOS and Android SDKs first, then added the web dashboard second. The SDK is where the work happens.
A note on how we stay honest about it
I want to be direct about something. We bill through Stripe, not the App Store. That means we're not taking a 30% platform cut on your users or your data. Your unit economics are transparent. You know exactly what you're paying per voter per month, and it doesn't inflate based on some platform's margin. Several studios told us they switched from competitors partly because of this. Not the sexiest reason to choose a tool, but it matters.
Passport lives on the Scale plan and above. We offer a free tier (Solo) for single apps with basic voting. Studio plan gets you up to five apps with full SDK support, but no cross-app identity. Scale and Portfolio both include Passport, along with webhooks and the deeper analytics you need when you're running a real portfolio.
The reason I mention this: we could have bundled Passport into every tier. It would look generous. But it would be dishonest. If you're running one app, you don't need it. If you're running multiple apps, it's worth the small jump to Scale. We'd rather be clear about that than pad the free tier with features nobody uses.
If you're managing feedback across more than a couple of apps and you've ever wondered whether the same person was voting multiple times, Passport's built for exactly that question. Does your current feedback tool even let you ask it?