When we started PerkClub, the obvious answer was to build an app. Every other membership and loyalty product I'd seen was an app. The members had to download something, log in, remember their password, and then — somewhere in the user flow — eventually use the perk they'd actually paid for. We chose not to build that.
The decision wasn't ideology. It came from drawing the user flow on a napkin and counting the open questions at every step. The app version had about fifteen. The wallet-pass version had three. So we built the one with three.
The user flow we cared about
The flow that mattered to us was the moment of redemption — the customer at the counter, ordering a coffee, with about six seconds before the line behind them gets impatient. If we got that flow wrong, none of the rest mattered. Members would stop using the membership, merchants would lose faith in the platform, and the whole thing would unravel.
On an app, redemption looks like: pick up the phone, find the app, tap to open, wait for it to load, log in if the session expired, navigate to the right screen, tap Redeem, hand the phone over. On a wallet pass, redemption looks like: pick up the phone, double-tap the side button, hand the phone over. The pass is already on the screen. There's nothing to find.
That's a six-second versus thirty-second difference. Multiplied across the rush hour at a coffee shop, it's the difference between a membership feeling effortless and a membership feeling like an obligation.
What an app would have given us
I want to be honest about the trade. An app gives you four things wallet passes don't: push notifications you control, deep customisation of the redemption screen, in-app analytics on user behaviour, and a habitable surface for future features. We gave all of those up.
Push notifications, in particular, are not nothing. The standard playbook for any consumer subscription is to drive engagement with notifications: "Your perk is expiring", "New seasonal item available", "Two days since your last visit". With a wallet pass, you get a single notification primitive — pass updates that surface as a banner — and that's it. We've made peace with that constraint, but it's a real constraint.
The customisation trade is similar. An app's redemption screen can be a beautiful animated object. A wallet pass is a card. There's a fixed shape and a fixed set of fields. You cannot put a custom illustration in a wallet pass and watch it scale across iOS versions. The pass is what it is.
What we got back
In return for those concessions, we got three things that mattered more than what we gave up.
1. Zero install friction
The biggest cost in any consumer product is the install step. Every percent of a funnel between "interested" and "installed" is a percent of customers you don't have. With wallet passes, the equivalent step is "Add to Wallet" — a one-tap interaction on a screen the user already trusts. The conversion rate from QR scan to active member is something we couldn't have come close to with an app.
For an independent shop, this matters more than for a chain. A chain can advertise its app on every receipt and bus stop in the country. An indie has one or two opportunities per customer to convert. The frictionless install is the difference between a membership that converts well at the counter and a membership that loses 60% of interested customers to the App Store.
2. The pass lives next to the bank cards
Wallet passes sit visually alongside credit cards, transit passes, and concert tickets in Apple Wallet and Google Wallet. That placement is psychologically valuable: the membership looks like financial infrastructure, not like another loyalty app. Members open the wallet because they always do; the pass is just there.
With an app, the membership lives in the App Store-shaped corner of the user's home screen next to a hundred other apps they barely open. We could not have designed our way out of that placement.
3. Operational simplicity for staff
The redemption side — the kiosk — is where the staff trade-off matters most. Staff don't have a PerkClub app on their till. They have a browser tab. The kiosk runs on whatever device the shop already owns: an iPad next to the espresso machine, a laptop in the back office, a phone in a pinch. The shop didn't buy hardware; we didn't write hardware drivers. Both of those are wins.
We've written more about how the kiosk side works on building software for shop staff.
The technical realities
The honest engineering picture is that wallet-pass infrastructure is harder than it looks from the outside. Apple Wallet (PassKit) and Google Wallet (Passes API) are mature but opinionated systems. They expect signed manifests, push-based pass updates over a mutual-TLS callback, and a particular style of error handling. The first time you debug a push that doesn't fire because your APNs cert rotated unexpectedly, you'll briefly miss the App Store.
We've spent a lot of engineering time making that infrastructure boring. The benefit is that the merchant experience above it is simple — design a plan, attach a QR code, and the passes are issued, updated, and revoked automatically. The cost is that we built and maintain a fairly rich pass-issuing service, with idempotent re-issuance, drift detection, and a fan-out mechanism for batch updates when a merchant changes branding. None of that is visible to the merchant, which is the point.
What we'd do again
If we were starting today, we'd make the same choice. The wallet-pass route demanded that we build a real backend with real opinions about state, identity, and update semantics — all of which we'd have had to build for an app anyway. The app would have added a frontend problem on top, with a release cadence we didn't want and a customer-acquisition cost that contradicted the product's whole point.
For a SaaS product whose users are professionals, an app is often the right call. For a consumer membership your customers use for thirty seconds at a time, three to five times a week, an app is overkill — and the install cost is high enough that you'll lose more customers than the marginal UX gain wins back.
Where it goes from here
Wallets are getting more capable, slowly. Apple Wallet now supports tap-to-pay-style interactions, richer pass content, and better update primitives than it had two years ago. Google Wallet has caught up significantly. We expect to keep getting more out of the platform without having to rebuild on top of an app.
If you're an indie shop weighing up whether to bother with the membership idea at all, the wallet-pass model is a major part of why it's now feasible to do without engineering help. That's a separate post, but you can see the live flow on the how-it-works page.
