The notification that changed how we think about feedback
Three weeks before launch, one of our early beta studios asked a question that made us stop everything: 'When someone votes for a feature and we ship it, how do they find out?' We didn't have an answer. That question became the reason push notifications aren't an afterthought in Shpd. They're woven into the product from the ground up.
The moment voting stops mattering
I'll be honest. Most feature-voting platforms treat notifications like a checkbox feature. You ship something, maybe an email goes out, maybe it doesn't. The voter eventually forgets they voted for it in the first place.
That felt broken to us. The whole point of asking your users what they want is to build trust. You're saying: we listen, we act, and you'll know when we deliver. If that last part fails, the loop closes. The voter never sees the payoff.
We're building for mobile app studios. That meant we couldn't rely on email alone. People check their inbox once a day if they're being generous. We needed something more immediate, more present. A push notification lands on a user's phone the moment a feature they voted for ships. Not tomorrow. Not when they remember to open the app. Now.
Native SDKs made this possible
Here's where the foundation matters. We didn't build Shpd as a web form that sits outside your app. We built native iOS and Android SDKs from the start. Your users vote inside your app. They see the voting board alongside your real product.
That decision meant we could wire push notifications directly into the SDK. When a studio deploys an updated build, the SDK already knows how to handle the moment a feature ships. It's not a separate integration or an API call you need to remember. It's built in.
Our Scale plan and above include this out of the box. The moment your backend tells us a feature is live, the notification fires to every voter who backed it, and it fires through the native notification system they expect. No web dashboard required. No email delay.
The closing of the feedback loop
I think about what happens on the user side. Someone votes for a feature in your app. They might vote for three or four things across your entire portfolio if you're a studio with multiple apps. Weeks pass. They stop thinking about it.
Then one day, a notification appears on their home screen. 'Dark mode shipped. Thanks for voting.' They open the app. They see the feature live. They feel heard.
That moment is what separates Shpd from every generic feedback tool. We're not collecting opinions in a vacuum. We're closing a promise. Studios tell us this is the reason their users feel loyalty. One studio in our beta said their retention jumped 8% after they shipped their first major feature request. They didn't change anything else. The only difference was their voters got a push notification.
Why this matters for studios managing many apps
A lot of our customers are building four, five, ten different apps. They might have a weather app, a social utility, a photography tool. Managing feedback across that portfolio used to mean separate Canny accounts, separate voting silos, fragmented voter lists.
Shpd's Passport system means one voter can participate across your entire portfolio with a single identity. They vote for weather features, photography features, social features. When any of those features ship, they get notified. One consistent experience across everything you build.
Push notifications become even more valuable at scale. A user votes for a feature in app A, forgets about it, and six months later ships a major update. The notification reminds them why they use your products. It's a tiny touch point that compounds over time.
The detail that nearly didn't make it
Honestly, we almost didn't prioritise this. In the early days, we thought we'd ship the voting board and the dashboard, then layer notifications on later. But that beta studio's question stopped us. They knew something we were still learning: the notification isn't a feature. It's the point of the whole system.
Building it into the native SDK from day one meant we could design around it. It meant thinking about what happens when a feature ship happens. It meant treating the voter's experience as something that extends beyond the moment they cast their vote.
Other platforms bolt this on. We built it in. That's the difference between a feedback tool and a feedback loop.
When you're asking thousands of users what they want from your apps, are you prepared to tell them when you've delivered? That's the question that shaped this feature, and it might be the question that shapes how your users think about your studio.