The App vs Web-Based Loyalty Decision
Many businesses default to "we need an app" when considering a loyalty programme. But a branded app requires significant investment (£20,000–£100,000+ for development), maintenance, and the barrier of asking customers to download it.
A QR-based web loyalty system or wallet pass delivers 80–90% of the same functionality at a fraction of the cost.
When a Branded App Makes Sense
A dedicated branded loyalty app is justified when:
- Your business has 10,000+ active loyalty members
- You need in-app ordering alongside loyalty (restaurant, coffee chain)
- Push notifications are a core engagement mechanism and wallet passes are insufficient
- You need deep integration between loyalty, payment, and ordering in one flow
Examples: Starbucks, McDonald's, Domino's — these apps combine ordering, payment, loyalty, and personalisation in a single experience that requires a native app.
When Wallet Passes or Web Solutions Are Sufficient
For most independent retailers, restaurants, and SMEs:
- Wallet pass (Apple/Google Wallet): No download, always accessible, push notifications via location-triggered passes, balance updates. Covers 80% of app functionality.
- Web-based loyalty portal: The customer's account is accessible via a link sent by email or SMS — no download, browser-based access, QR displayed in browser.
- QR stamp card platforms (Loopy, Stamp Me): No app for customer — they use a browser link or the platform's generic app (not a branded app).
Cost Comparison
| Solution | Setup Cost | Monthly Cost |
|---|---|---|
| Branded native app | £20,000–100,000 | £500–2,000 (maintenance) |
| Wallet pass platform | £0–500 | £20–100 |
| Web loyalty platform | £0–2,000 | £20–200 |
| Paper stamp cards | £50 (printing) | £20–50 (reprinting) |
For most SMEs, a wallet pass + web portal solution delivers the best ROI for loyalty.
Putting this into practice
Start with the smallest real test you can run. Generate the code, print it at the exact size you plan to use, and scan it with two different phones in the lighting where it will live. Check that the destination page loads quickly on a mobile connection and that the call to action next to the code tells people what they will get. If anything feels slow or unclear, fix it before you print a full batch, because reprints cost more than a short test. Keep a note of the size, material, and placement that worked so the next batch starts from a proven setup.
Common mistakes to avoid
The most common mistakes are easy to avoid once you know them. Long payloads make modules tiny, low contrast makes edges hard to read, and text placed too close to the border eats the quiet zone the scanner needs. Covering a corner finder pattern with a logo or a sticker breaks detection entirely, and a code placed behind glare or on a curved surface fails even when the print is perfect. Review each of these points on a proof copy, and treat any failure as a reason to adjust the design rather than a reason to blame the scanner.
Quick checklist
- Keep the payload as short as practical so modules stay large.
- Keep dark modules on a light background with strong contrast.
- Leave a clear quiet zone on all four sides of the symbol.
- Test the printed code at the real viewing distance and lighting.
- Confirm the destination page loads fast on a phone.
- Recheck the code after any change to the link, design, or placement.
Related tools and guides
- For local payments, the [Pakistan payment QR](/pakistan-payment-qr) page explains the regional flow and what customers see.
- The [regional payment QR](/regional-payment-qr) guide covers payment codes used across different markets.
- The [bulk generator](/bulk-generator) builds many codes from a table when one-off generation would take too long.
- Test every code with the [QR scanner](/qr-scanner) on more than one phone before you publish or print it.
- The [UTM builder](/utm-builder) adds campaign parameters so scans show up separately in your analytics.
- The [blog](/blog) collects more guides on sizing, printing, security, and payments for QR codes.
