Een native app bouwen is voor veel ondernemers de eerste gedachte zodra ze iets willen waarmee klanten of medewerkers op hun telefoon kunnen werken. Dat gevoel is begrijpelijk: een app in de App Store of Google Play heeft iets tastbaars. Toch is die keuze in de praktijk duurder, trager en beperkter dan de meeste opdrachtgevers van tevoren verwachten. Een Progressive Web App, kortweg PWA, levert in veruit de meeste zakelijke situaties hetzelfde resultaat tegen aanzienlijk minder budget en zonder de afhankelijkheid van Apple of Google.
Wat een PWA onderscheidt van een gewone website
Een PWA is geen website met een mooi icoontje. Achter die term gaat een set technische afspraken schuil die ervoor zorgt dat een webapplicatie zich gedraagt als een native app: installeerbaar op het thuisscherm, werkt ook bij een slechte verbinding, kan push notificaties versturen en laadt razendsnel door slimme caching via een service worker. Het resultaat op het scherm van de gebruiker is vrijwel niet te onderscheiden van een app die via de App Store is gedownload.
Technisch gezien zet je een aantal zaken op: een web app manifest, een service worker die verzoeken onderschept en cached pagina's serveert wanneer de verbinding wegvalt, en een beveiligde HTTPS-verbinding als basis. Dat klinkt omvangrijker dan het is. In projecten die ik op die manier bouw, zit dit al in de basisarchitectuur verwerkt, zodat het geen losse toevoeging achteraf is maar onderdeel van het fundament.
Waar het voor ondernemers op neerkomt: je laat één applicatie bouwen die werkt op iOS, Android, Windows en elke andere omgeving met een moderne browser. Dat is fundamenteel anders dan een native app, waarbij je voor iOS en Android aparte codebases hebt die allebei onderhouden moeten worden.
Wat een native app kost, en waarom dat optelt
De minimale investering voor een native app die er verzorgd uitziet en fatsoenlijk werkt op zowel iOS als Android ligt al snel tussen de 25.000 en 60.000 euro, afhankelijk van de gewenste functionaliteiten. Dat is niet omdat developers gierig zijn, maar omdat je twee keer bouwt: een iOS-versie in Swift of React Native voor Apple, en een Android-versie die ook nog eens getest moet worden op tientallen verschillende schermformaten en Android-versies.
Daarna begint het eigenlijk pas. Apple en Google beoordelen elke update die je naar de stores wilt sturen. Dat reviewproces duurt gemiddeld één tot drie dagen, wat betekent dat een spelfout corrigeren of een bug fixen niet dezelfde dag live kan. Wil je een functionaliteit aanpassen omdat je bedrijfsproces verandert? Dan wacht je opnieuw. Een PWA kent dat mechanisme niet: een aanpassing gaat live op het moment dat de code op de server staat.
Tel daarbij op dat Apple 30% van elke betaalde transactie via de App Store afsnoept, en Google in veel gevallen niet veel minder. Voor een webshop, portaal of abonnementsdienst is dat een structurele kostenpost die bij een PWA niet bestaat. Betalingen verwerk je dan via een eigen koppeling met Stripe of Mollie, waarbij de volledige marge bij jou blijft.
Wanneer een PWA tekortschiet
Eerlijk zijn over de grenzen van een PWA is minstens zo belangrijk als de voordelen beschrijven. Er zijn situaties waarin een native app de betere keuze is, en die moet je als ondernemer kennen voordat je een beslissing neemt.
Diepe hardware-integratie is het meest concrete voorbeeld. Wil je continu op de achtergrond de GPS-locatie bijhouden, bluetooth-apparaten aansturen, of toegang tot versnellingsmeters voor een fitnessapp? Dan zit je bij een PWA sneller tegen de grenzen van wat browsers toestaan. Apple in het bijzonder heeft jarenlang PWA-mogelijkheden op iOS beperkt gehouden, al zijn die beperkingen de laatste jaren gedeeltelijk weggevallen. Voor een bezorgdienst die de chauffeur real-time wil volgen terwijl de telefoon op slot staat, is een native app nog altijd betrouwbaarder.
Augmented reality, intensieve grafische verwerking of toepassingen die zwaar leunen op de GPU van het apparaat vallen ook in die categorie. Maar voor verreweg de meeste zakelijke toepassingen, denk aan portalen voor medewerkers, klantomgevingen, reserveringssystemen, ledenadministraties, orderbeheer of interne tools, speel je op dat niveau helemaal niet. Die toepassingen zijn prima te bouwen als PWA, en dat doe ik dan ook.
De praktische afweging voor jouw project
De kernvraag die elk project voor mij bepaalt: wat moet de app kunnen doen, en wie zijn de gebruikers? Een field service-applicatie voor monteurs die onderweg formulieren invullen, foto's maken via de camera en hun rapport opslaan, werkt prima als PWA. De camera-API is al jaren beschikbaar in browsers, en met een goede service worker werkt het formulier ook als er geen bereik is op de locatie, waarna het synchroniseert zodra de verbinding er weer is.
Gaat het om medewerkers of klanten die de app dagelijks nodig hebben maar niet technisch zijn? Dan is de drempel van "ga naar de website en voeg toe aan je thuisscherm" voor sommige doelgroepen hoger dan het downloaden van een app uit de store. Dat is geen technisch probleem maar een gebruikerservaring-probleem, en het is eerlijk om dat mee te wegen. In de praktijk lossen onboarding-schermen en een duidelijke installatieprompt dat voor een groot deel op.
Wat ik in projecten merk, is dat de totale eigendomskosten over drie jaar voor een PWA structureel lager liggen dan voor een native app. Geen dubbele codebases, geen store-afhankelijkheid, updates die dezelfde dag live gaan, en één technische basis die onderhoud een stuk overzichtelijker maakt. Voor een MKB-ondernemer die een digitaal product wil bouwen zonder een eigen development-team, is dat een sterk argument.
De keuze wordt pas interessant wanneer je echt in hardware-features duikt of wanneer je weet dat 80% van je gebruikers al een native app verwacht in een omgeving waar dat de standaard is. Voor een consumentenspel of een app die concurreert met TikTok heeft een native aanpak zijn redenen. Voor een zakelijke toepassing, een portaal of een interne tool is een PWA zelden de verkeerde keuze.
Als je twijfelt: schrijf op wat de app moet kunnen. Niet in technische termen, maar in gedrag. Wat doet een gebruiker ermee, wanneer, en op welk apparaat? Met die lijst is de afweging in de meeste gevallen snel gemaakt, en je hoeft niet te investeren in iets wat je drie keer zoveel kost terwijl het eindresultaat voor de gebruiker nauwelijks verschilt.
Mijn voorkeur voor PWA's in zakelijke projecten is niet ideologisch maar pragmatisch. Het levert sneller een werkend product op, het houdt de architectuur overzichtelijk, en het geeft jou als opdrachtgever meer controle over het platform zonder dat je afhankelijk bent van een techgigant die de spelregels eenzijdig kan aanpassen.
Op https://pimvdmolen.nl/diensten/progressive-web-apps lees je hoe ik PWA-projecten aanpak en welke stappen daarbij komen kijken. Wil je sparren over of een PWA past bij jouw specifieke situatie, neem dan contact op via https://pimvdmolen.nl/contact.