Between 2017 and 2020, PWA was a technology hype cycle. Conferences, blog posts, official support from Google and Microsoft. Then came the disappointment — iOS kept key APIs closed, install prompts turned out to be confusing, the marketing of native apps was still stronger. The community moved on to Flutter, React Native and Capacitor.
But something else happened quietly. The PWA stack kept maturing. Apple has added the missing APIs over the last few years, browsers improved the install flow, the service worker spec settled. And for product teams without a big budget, PWA has become a surprisingly strong option.
This article is an honest case study of trefa.app — a company prediction pool built as a PWA — after a year in production. What worked, what did not, and who I would recommend PWA to today.
Context: what trefa.app is
Trefa.app is a web app for company prediction pools. The user signs in with Google, creates a league for their company, invites colleagues via a link or a QR code, and they predict match results together. The app syncs data from sports APIs (NHL, Premier League, World Championships) and recalculates points in real time.
The frontend is Next.js 16 + React 19 + Tailwind, hosted on Vercel. The backend is Django 5 + DRF + Channels on Hetzner. In between, PostgreSQL on Supabase and Redis for real-time comms.
A pleasant detail: there is no native iOS or Android app. The PWA is the only client. Users on iPhone, Android, Windows and macOS use exactly the same thing.
Why we went PWA instead of native
The decision was largely economic. A native app would have meant:
- Developing two parallel clients (iOS Swift + Android Kotlin), or a cross-platform framework (Flutter, React Native).
- App Store + Google Play submission process — submission fees, review delays, periodic re-publishing on backend API changes.
- Push notifications via APNs and FCM, two separate infrastructures, two certification processes.
- Update flow through stores — the user has to actively update, a chunk of users stay on an older version for months.
For a product with a relatively small target audience (company teams, not mass market), the cost of native development was significantly higher than the benefit. PWA removed all of the above at once.
Technical advantages users will never notice
This is the part I would have underestimated before going to production. From a development standpoint, PWA brings a number of concrete advantages that save weeks of work per year:
Deploy is instant. Push to main → Vercel builds → in 2 minutes the new version is in front of all users. No submission, no waiting, no compatibility juggling between client and backend versions. If I make a breaking API change, the next day I can ship a fix and everyone has it immediately.
One codebase for everything. iOS, Android, Windows, macOS, Linux — the same app everywhere. No platform-specific bugs ("this breaks only on iPhone 13 in dark mode"), no duplicated implementation.
Short path to the user. Send a link, click, in the app. No "download our app from the App Store, register and then sign in". For B2B products with low-frequency use (a prediction pool runs only during a sports tournament), this is a huge conversion benefit.
Push notifications work even without install. The service worker registers the push subscription. Once the user clicks "Allow notifications", they start receiving alerts before matches regardless of whether they have added the app to the home screen or just occasionally open it in Safari.
What PWA cannot do (honest section)
Honesty matters more than marketing here. PWA has real limits we have hit in production.
iOS push notifications come with strings attached. Apple Web Push has existed since iOS 16.4, but only works if the user has added the PWA to the home screen. If they use the app via Safari tabs, the push subscription does not stick. That is friction native apps do not have.
App Store presence is missing. For some buyer personas (HR departments, enterprise IT managers) "not in the App Store" is equivalent to "not serious". Subjective, but real.
Some OS APIs are not available. Bluetooth Low Energy, NFC, full file system access — for a typical app this is fine, but if you need these features, PWA limits you.
Offline mode is possible, but not automatic. The service worker has to be set up manually, cache strategies designed, sync queues implemented. For a fully offline-first app this is more work than developers expect.
Performance benchmark vs. native: PWA is ~15–25 % slower on the first load (JS bundle parsing) and ~5–10 % in everyday interactions. For most apps imperceptible, for hardcore gaming or video editing a dealbreaker.
Results after a year in production
Concrete data from trefa.app after a year of running:
- Cross-platform stability — a development team of one person maintains the app on all operating systems without platform-specific bugs. Same testing cycle for all.
- Deploy frequency — on average 3–5 deploys per week via Vercel. None of them dealing with App Store submission delays.
- Push notifications — ~70 % of users active, push delivery rate ~95 % on Android, ~85 % on iOS (because of the home-screen install requirement).
- No App Store fees — saved roughly 70 USD a year on developer accounts plus roughly 30 % commission on transactions (which would otherwise apply for in-app purchases).
The main business benefit, however, was not technical. It was iteration speed. If a customer wrote "this feature would help me", I usually started on it the same day and shipped within the week. That is simply not possible with a native app.
Who I would recommend PWA to today
PWA is a fit if at least two of the following hold:
- You have limited resources and cannot afford two native apps plus a web version.
- Your users use the app occasionally (not every day), so low friction at first open matters.
- Your app does not need hardcore OS APIs (Bluetooth, NFC, full file system).
- You want to deploy without app stores in the way.
- Your audience is mixed — iOS plus Android, mobile plus desktop.
PWA is probably not the right call if:
- Your app runs daily, several hours a day, and users use it intensively (social media, messaging).
- You need advanced OS integrations.
- Your buyers expect an App Store presence.
- Performance is critical (gaming, video, AR).
Conclusion
The PWA hype may be over, but the technology has quietly grown into a point where, for many products, it is a better choice than going native. Trefa.app has been on PWA for a year and I see no reason to change it. On the contrary — if I were starting again today, I would go in faster.
If you are weighing PWA against a native app for your project, take one thing into account beyond the technical arguments: PWA gets you to production faster. And in the early stages, iteration speed is more valuable than anything else.
By the way, you can try trefa.app yourself — no install, just a click and you are predicting.