Klantportaal: app of responsive website?

De vraag achter de vraag

"Moet ons klantportaal een app of een website worden" is bijna nooit de vraag die je écht moet beantwoorden. De vraag die er onder ligt is: wat doen onze klanten in dat portaal, hoe vaak doen ze het, en wat moet er gebeuren als ze het doen op een plek met slecht netwerk, in een gehaast moment, of zonder dat ze er bewust voor kiezen om in te loggen.

Een verzekeraar met een schade-portaal heeft een ander profiel dan een aannemer met een werknemersportaal of een hosting-provider met een klantdashboard. Sommige klantportalen worden één keer per kwartaal geraadpleegd; andere worden tien keer per dag geopend. Sommige hebben alleen een formulier en een PDF; andere willen camera-uploads, locatiedata of biometrische login. De juiste oplossing volgt uit het profiel — niet uit de wens om "ook een app te hebben omdat de concurrent er een heeft".

Drie technische vormen

Voordat we de criteria langsgaan, drie definities die door elkaar gebruikt worden:

Responsive website

Een website die op desktop, tablet en telefoon werkt via de browser. De gebruiker logt in op een URL, doet wat hij moet doen en sluit het tabblad. Geen installatie, geen App Store, geen aparte build per platform. Onder de motorkap kan dat een server-rendered site zijn, een Single-Page Application of een hybride; voor de gebruiker maakt het niets uit. Zie ook onze diepere uitleg over een Single-Page Application laten maken als alternatief binnen de web-categorie.

Progressive Web App (PWA)

Een PWA is een website die zich gedraagt als een app: hij kan worden geïnstalleerd op het beginscherm, werkt deels offline via een service-worker-cache, kan push-notificaties ontvangen (op Android volledig, op iOS sinds iOS 16.4 met beperkingen) en heeft een eigen icoon. Maar hij wordt niet via de App Store of Google Play gedistribueerd — de gebruiker installeert hem vanuit de browser. Een tussenoplossing die voor sommige scenario's beter past dan de andere twee. We hebben er een aparte gids over: wat is een Progressive Web App vs native app.

Native app

Een echte native app wordt gebouwd in Swift of Kotlin (of in een cross-platform framework als Flutter, React Native of .NET MAUI) en wordt verspreid via de App Store en Google Play, of via Mobile Device Management voor zakelijke distributie. Hij krijgt diepe toegang tot device-features, draait in de achtergrond, integreert met systeem-niveau push-notificaties en kan biometrische authenticatie aanroepen.

De drie vormen zijn geen sloten waar je in zit voor altijd — je kunt beginnen met een responsive site, daarna PWA-laag toevoegen, en pas later een native app bouwen als de cijfers dat rechtvaardigen. Ownership van data en logica blijft bij je; alleen de schil verandert.

Criterium 1: gebruiksfrequentie

De zwaarste voorspellende factor. Hoe vaak per dag, week of jaar opent een gemiddelde klant het portaal?

Klantportalen waar gebruikers maandelijks of minder vaak komen — een factuur ophalen, één keer per kwartaal een formulier indienen, een polis bekijken — passen vrijwel altijd het beste bij een responsive website. De drempel om eerst een app te installeren wordt voor zo'n lage frequentie te hoog; klanten loggen liever in vanuit een e-mail-link of een zoekresultaat. App-installaties die na drie keer gebruik weer worden weggegooid zijn een budget-lek dat je niet ziet maar wel betaalt.

Klantportalen waar gebruikers wekelijks komen — een leverancier-portaal voor inkoop, een werknemersportaal voor declaraties, een dealer-portaal voor bestellingen — zitten in de PWA-zone. Hoog genoeg om "installeren" zinvol te maken, niet hoog genoeg om de App-Store-kosten van een echte app te rechtvaardigen. Een PWA op het beginscherm voelt voor de gebruiker als een app, zonder dat jij twee native codebases onderhoudt.

Klantportalen waar gebruikers dagelijks of meerdere keren per dag komen — een logistiek-portaal voor chauffeurs, een service-portaal voor monteurs, een patiëntenportaal voor chronische zorg — verdienen serieus de afweging om naar een native app te gaan. Op dat frequentie-niveau wegen on-device performance, achtergrond-sync, push-betrouwbaarheid en biometrische login zwaar genoeg om de meerkosten in onderhoud te rechtvaardigen.

Criterium 2: offline-modus

Werken jouw gebruikers regelmatig op plekken met slecht of geen netwerk? Een buitendienst-monteur in een ketelhuis, een chauffeur in een tunnel, een verpleegkundige in een ziekenhuis met dode hoeken, een inspecteur op een afgelegen locatie — als "geen netwerk" een dagelijks scenario is, is een responsive website geen optie. Een browser-tab werkt niet zonder verbinding (afgezien van wat hij toevallig in de cache heeft staan).

Een PWA kan met een service-worker een offline-laag bieden: gecachte schermen blijven beschikbaar, formulieren kunnen worden opgeslagen en gesynchroniseerd zodra verbinding terugkomt. Voor lichte offline-scenario's is dat genoeg. Voor zware offline-scenario's — bijvoorbeeld een werkbon-app die uren zonder verbinding moet kunnen werken, met conflict-resolution als twee monteurs dezelfde order bewerken — heb je de databasecontrole van een native app nodig: lokale SQLite of een sync-engine als WatermelonDB of Realm, achtergrond-sync via OS-niveau scheduling.

De ruwe vuistregel: offline-uren = minuten → PWA volstaat. Offline-uren = uren of dagen → native app.

Criterium 3: push-notificaties

Push is een vak op zich. Een responsive website kan technisch geen push-notificaties versturen — daarvoor heb je minimaal een PWA nodig (op Android al langer; op iOS sinds 16.4 in 2023 met beperkingen rond geïnstalleerde web-apps). Een native app krijgt volledige toegang tot het notificatie-systeem, inclusief rich notifications, action-buttons, geofencing-triggers en achtergrond-categorisering.

Hoe critical is push voor jouw portaal? Een paar voorbeelden uit praktijk:

• Critical: een zorg-portaal dat een patiënt waarschuwt voor medicatie-tijd. Mist hij de push, ontstaat schade. Native app, eventueel met critical-alerts-permissie op iOS.
• Belangrijk: een service-portaal dat een monteur een nieuwe order pusht zodra die binnenkomt. Een gemiste push betekent een gemiste afspraak; native of een goed-werkende PWA volstaat.
• Nice-to-have: een klant-portaal dat eens per kwartaal een herinnering stuurt om een formulier in te dienen. E-mail kan dat ook doen; responsive website met e-mail-trigger is genoeg.

De fout die we het vaakst zien: een opdrachtgever zegt "push is belangrijk" omdat het bij een app hoort, terwijl het gebruiksprofiel laat zien dat e-mail of SMS net zo goed zou werken. Push kost je een app-traject; weeg het op echte impact, niet op default-aanname.

Criterium 4: hardware-toegang

Welke device-features heb je nodig vanuit het portaal? Browser-APIs zijn de afgelopen jaren krachtig geworden, maar er blijven gaten waar alleen een native app de oplossing is.

Camera

Foto's maken en uploaden kan de browser inmiddels op alle moderne telefoons. Voor een schade-portaal of een PIM-portaal met productfoto's is dat genoeg. Wat de browser niet kan: real-time AR-overlay, geavanceerde scan-modus voor barcodes of QR-codes in lage lichtomstandigheden, of camera-toegang in de achtergrond.

GPS en locatie

Locatie ophalen lukt in de browser, maar alleen als de tab actief is. Achtergrond-locatie — bijvoorbeeld voor het automatisch loggen van werktijden bij aankomst op een klantadres, of voor geofencing-notificaties — werkt alleen in een native app met de juiste permissies.

Biometrie

Face ID en Touch ID kunnen via de WebAuthn-standaard in een browser worden aangeroepen, maar de UX is grover dan in een native app. Voor een portaal waar biometrische login een dagelijkse handeling is — een banking-app, een zorg-portaal met patiëntendata, een verzekerings-portaal met dossiers — voelt een native implementatie aanzienlijk natuurlijker.

NFC, Bluetooth, sensoren

NFC voor kaartlezers, Bluetooth voor IoT-koppeling met meetapparatuur, accelerometer voor stappen-tellen — vrijwel alleen native. Web-Bluetooth bestaat maar werkt niet op iOS-Safari, en dekking op Android is fragmentarisch.

Criterium 5: branding en experience

Een native app krijgt een eigen plek op het beginscherm, een eigen splash-screen, een eigen taakomschakelaar-kaart. Hij voelt voor de gebruiker als een eigenstandig product. Voor merken die hun klantrelatie willen versterken — premium-dienstverleners, abonnement-modellen, langdurige relaties — heeft dat waarde die je in een browser-tab niet krijgt.

Een PWA komt aardig in de buurt: icoon op beginscherm, full-screen modus, eigen splash, eigen kleuren. Voor de meeste branding-doelen is dat genoeg, en op iOS Safari is het verschil tussen een geïnstalleerde PWA en een native app voor de gemiddelde gebruiker niet merkbaar.

Een responsive website verstopt zich tussen de tabs. Hij krijgt geen branded-omgeving, geen splash, geen achtergrond-presence. Dat is geen probleem voor portalen waarvan de waarde puur transactioneel is (factuur ophalen, formulier indienen) — maar voor portalen waarvan engagement de gewenste uitkomst is, is het een kostenpost in user-experience.

Criterium 6: SEO en findability

Hier draait de afweging om. Een klantportaal achter een login hoort uit search-engines te blijven — dat is een security-eis, geen SEO-doel. Maar de marketingpagina's die naar het portaal toe leiden moeten wél vindbaar zijn: een uitleg-pagina, een onboarding-flow, eventueel een demo-account.

Een responsive website integreert daar moeiteloos mee: dezelfde tech-stack, dezelfde URL-structuur, dezelfde SEO-aanpak. De marketing-pagina staat in Google, de gebruiker klikt door, logt in op exact dezelfde site, en zit in zijn portaal. Geen context-switch, geen dubbele branding.

Bij een PWA werkt dat ook — de PWA is per definitie een website, hij heeft alleen extra installatie-mogelijkheid. De marketing-pagina en de installeerbare app delen URL-stam en analytics.

Een native app vergt een aparte marketing-funnel: een landingspagina die de App Store-installatie als doel heeft, App Store Optimization, en analytics-attribution om te weten welke campagne welke install heeft opgeleverd. Niet onmogelijk, maar wel een tweede vakgebied bovenop wat je voor de website al doet.

Criterium 7: AVG en EU-residency

Een klantportaal verwerkt vrijwel altijd persoonsgegevens — en in veel gevallen ook bijzondere persoonsgegevens (gezondheid, financiën, identiteit). Dat brengt AVG-verplichtingen mee die ongeacht het platform gelden, maar die op een aantal punten anders uitvallen voor app dan voor web.

Voor zowel de website als de app gelden dezelfde fundamenten: rechtmatige grondslag voor verwerking, dataminimalisatie, beveiliging in lijn met de stand van de techniek, Data Processing Agreements met sub-verwerkers, een mechanisme voor inzage- en verwijderingsverzoeken, en datalekken binnen 72 uur melden bij de Autoriteit Persoonsgegevens.

EU-residency van data is een terugkerend punt: veel zakelijke afnemers eisen dat hun klantdata binnen de EU blijft staan en niet onderworpen is aan Amerikaanse jurisdictie-vereisten zoals de CLOUD Act. Praktisch betekent dat hosting bij een EU-cloudprovider, of EU-regio's bij hyperscalers, of in een aantal sectoren een private cloud. Die keuze geldt voor je backend, en de keuze voor app vs website verandert daar niets aan — beide praten met dezelfde API en dezelfde database.

Waar het wel verschilt: de app brengt een extra speler binnen — Apple of Google. Een native app moet voldoen aan App Store Review Guidelines en Google Play Policies, die boven op de AVG eigen privacy-eisen leggen (privacy-labels, app-tracking-transparency, opt-in voor identifiers). Voor een portaal met gevoelige data is dat een tweede compliance-stack waar je doorheen moet — niet onoverkomelijk, maar wel inspanning. Een responsive site of een PWA omzeilt deze stack volledig.

European Accessibility Act (EAA) en WCAG 2.2 gelden vanaf 28 juni 2025 voor commerciële digitale producten, en de richtlijnen omvatten zowel websites als apps. Een klantportaal van een grote dienstverlener moet aan WCAG voldoen, ongeacht of het in een browser of in een app draait. Wie nu nog bouwt zonder accessibility-baseline bouwt voor herbouw.

Criterium 8: lange-termijn ownership

Wie is er over vijf jaar nog eigenaar van de code, de data en de relatie met je klanten?

Bij een responsive website en een PWA is het antwoord eenduidig: jij. Je eigen domein, je eigen hosting, je eigen codebase, je eigen analytics. Geen tussenpartij die op enig moment policy kan wijzigen of accounts kan opheffen.

Bij een native app komen Apple en Google als blijvende intermediairs in de keten. Zij kunnen je app uit de Store halen als die volgens hen niet voldoet aan een (nieuwe) richtlijn, ze kunnen commissies wijzigen, ze kunnen technische requirements afdwingen die je niet had voorzien. In de praktijk werken die platforms voorspelbaar genoeg om er een product op te bouwen, maar wie zegt "ik wil zelf in control zijn over alle aspecten" loopt langs deze afhankelijkheid.

Hetzelfde geldt voor cross-platform frameworks: Flutter is van Google, React Native van Meta, .NET MAUI van Microsoft. Je hebt een dependency op die roadmaps. Voor een uitgebreidere kijk op wat eigenaarschap betekent voor budget en risico verwijzen we naar onze gids over maatwerk-software-kosten, die ingaat op total cost of ownership over een traject van meerdere jaren.

Wanneer kies je een responsive website

De responsive-website-keuze is verdedigbaar in deze profielen:

• Klanten bezoeken het portaal maandelijks of minder vaak. Een app-installatie zou voor de meesten verspilde drempel zijn.
• De content is overwegend documenten, formulieren of dashboards. Geen camera-overlay, geen achtergrond-locatie, geen biometrische dagelijkse login.
• Het portaal moet werken op een breed apparaatbereik: kantoor-desktop, oudere bedrijfslaptop, smartphone, tablet. Eén codebase die overal werkt, in plaats van twee native builds plus een web-fallback.
• Findability speelt een rol: een deel van het portaal of het verkooptraject ernaartoe moet in zoekresultaten verschijnen.
• Je wil sneller live dan een dubbele build-cyclus toestaat. Web-deployment is een directe push naar productie; app-distributie wacht op store-review.
• Lange-termijn ownership en onafhankelijkheid van platform-policies wegen zwaar.

Concrete voorbeelden uit onze praktijk: een verzekeraar met een polishuis-portaal voor consumenten, een accountantskantoor met een klant-dashboard voor jaarstukken, een vastgoedbeheerder met een huurder-portaal voor reparatiemeldingen. Allemaal portalen waar de gebruiker enkele keren per jaar tot enkele keren per maand inlogt — een app zou geld kosten zonder dat de gebruikswaarde stijgt.

Wanneer kies je een PWA

De PWA wint vooral als je wekelijks gebruik hebt, push wenselijk is en je de App-Store-overhead wilt vermijden. Specifiek:

• Klanten gebruiken het portaal wekelijks tot enkele keren per week. Genoeg om "installeren" zinvol te maken; niet genoeg om twee native codebases te rechtvaardigen.
• Push-notificaties zijn nuttig maar niet kritiek. De PWA pushed prima — alleen wat geavanceerder push-functionaliteit (geofencing, critical alerts) blijft buiten bereik.
• Lichte offline-modus is genoeg. Het portaal moet bij wegvallende verbinding nog enkele schermen kunnen tonen en formulieren kunnen wegschrijven voor latere sync.
• Je hebt geen diepe hardware-features nodig: foto-upload uit camera ja, achtergrond-camera nee; locatie bij actief-tab ja, geofencing nee.
• Je wil niet door App-Store-review heen voor elke kleine update. Een PWA krijgt updates op het moment dat je hem publiceert, zonder review-wachttijd.
• Distributie via een eigen URL of een QR-code is voor jouw doelgroep haalbaar — geen App-Store-discovery nodig.

Concreet: dealer-portalen voor inkoop, leveranciers-portalen voor onderhanden-werk, B2B-klantportalen waar een vaste groep gebruikers met de app werkt. Voor diepere verdieping op de PWA-keuze hebben we een aparte gids over de vergelijking PWA versus native app.

Wanneer kies je een native app

Er zijn scenario's waarin geen PWA of website het volume aankan dat de native app oplost. De zwaarste:

• Dagelijks of meerdere keren per dag gebruik door dezelfde groep. Een app op het beginscherm verlaagt de drempel voor herhaald gebruik aanzienlijk.
• Zware offline-modus: uren of dagen zonder verbinding moeten productief blijven, met lokale data-opslag, conflict-resolution en achtergrond-sync.
• Critical push: missen van een notificatie betekent harm voor de eindgebruiker (zorg, veiligheid, logistiek met SLA-eisen).
• Diepe hardware-toegang: achtergrond-GPS, NFC, Bluetooth-pairing met IoT-apparatuur, AR-overlay op de camera, biometrische dagelijkse-login.
• Premium-merkbeleving: het portaal is onderdeel van een merk-experience waarbij de eigen ruimte op het device waarde toevoegt.
• De distributie loopt via Mobile Device Management van de klant — een werkgever installeert de app op de beheerde toestellen van zijn werknemers. Een PWA werkt daar wel maar voelt anders dan de MDM-managed app-suite.

Concreet: een service-app voor monteurs, een werknemersportaal met dagelijks gebruik (zie onze pagina over een werknemersportaal laten maken voor de bredere context), een patiënten-app met medicatie-alerts, een chauffeurs-app voor logistieke planning. Voor het bredere kader van wanneer een app überhaupt past, zie onze hoofdpagina app-ontwikkeling.

Een hybride strategie

De drie vormen sluiten elkaar niet uit. Sterker: voor veel klantportalen is een gefaseerde strategie de beste route.

Begin met een responsive website. Dat is bijna altijd de eerste bouwsteen — de marketing-pagina's en de portaal-functies delen URL-stam, codebase en branding. Hij is sneller live en goedkoper in onderhoud dan een dubbele app-build.

Voeg na enkele maanden van real-world gebruik een PWA-laag toe als de cijfers laten zien dat klanten wekelijks of vaker terugkomen. Service-worker, manifest, installeerbaarheid, basis-push. Dat is een uitbreiding van de bestaande codebase, geen herbouw.

Bouw pas een native app als de PWA-cijfers tegen plafond lopen: dagelijks gebruik door een grote groep, hardware-features die je in browser niet krijgt, push die kritischer wordt, of expliciete enterprise-deals die "een echte app" als requirement vragen. Op dat moment is de back-end al volwassen, weet je welke features echt gebruikt worden, en bouw je een schil die specifiek daarvoor optimaliseert.

De gefaseerde aanpak vermijdt het klassieke faalpatroon: een eerste-versie native app die op dag één leeg is, geen gebruikers heeft en geen feedback genereert, terwijl een team van native developers maandlasten oplevert die het project moeten dragen. Begin licht, schaal op wat werkelijk traction krijgt.

Veelgestelde vragen

Werkt de AVG anders voor een app dan voor een website?

De materiele eisen — grondslag, dataminimalisatie, beveiliging, transparantie — zijn identiek. Wat verschilt: een app brengt Apple en Google als tweede compliance-laag mee, met hun eigen privacy-policies en data-handling-eisen die je naast de AVG aflegt. Een website ontloopt die laag.

Geldt de European Accessibility Act voor klantportalen?

Ja. Vanaf 28 juni 2025 vallen commerciële digitale producten en diensten onder de EAA, en dat omvat zowel apps als websites. WCAG 2.2 op niveau AA is in praktijk de baseline. Voor zakelijke portalen die alleen voor één afnemer worden gebouwd is de directe verplichting smaller, maar accessibility-by-design is hoe dan ook de richting waarin alle wetgeving beweegt.

Kan een PWA op iOS net zo veel als op Android?

Bijna, maar niet helemaal. Sinds iOS 16.4 (begin 2023) ondersteunt Safari geïnstalleerde PWA's met web-push, maar de geavanceerde push-features (rich media, action-buttons, geofencing) zijn voller op Android. Voor een PWA-strategie die zwaar op iOS-gebruikers leunt is het zinvol om de iOS-specifieke beperkingen vooraf in kaart te brengen.

Hoe zit het met App-Store-commissies voor een klantportaal?

Apple en Google rekenen 15 tot 30 procent commissie over in-app-purchases en abonnementen. Voor een klantportaal dat geen consumenten-betalingen in de app verwerkt — een werknemersportaal, een leveranciers-portaal, een B2B-klantdashboard zonder transactionele betalingen — speelt dit niet. Het wordt relevant zodra je consumenten direct in de app laat afrekenen.

Is een PWA SEO-vriendelijk?

Een PWA is een website met extra-laag — zijn publieke pagina's worden gewoon geïndexeerd. Achter de login speelt SEO geen rol; dat is de bedoeling. De marketing-laag van een PWA werkt SEO-technisch identiek aan een gewone responsive website.

Kunnen we ooit later van een responsive site naar een app overstappen?

Ja, en dat is voor veel klantportalen de slimste route. De back-end (API, database, business-logic) blijft hetzelfde; alleen de schil wordt aangevuld. De webfunctionaliteit hoeft niet weggegooid te worden — die blijft beschikbaar voor klanten die geen app willen installeren of die liever in de browser werken.

Wat kost een app of een portaal te bouwen?

Het hangt af van scope, integraties en eisen op offline, hardware en multi-tenancy. Een eenvoudig klantportaal met een paar formulieren en een document-archief is een ander traject dan een portaal met multi-tenancy, SSO, audit-log en realtime-koppelingen aan een ERP. Wij geven na een kennismaking een indicatie op basis van het specifieke profiel.

Geldt de keuze óók als de gebruiker zelf de keuze niet kan beïnvloeden?

Ja, en juist dan is hij belangrijk. Een werknemersportaal of een leveranciersportaal dat je medewerkers verplicht moeten gebruiken raakt direct hun werkbeleving. Een verkeerd-gekozen vorm — een app waar geen ruimte voor is om er door te komen, of een website waar een belangrijke offline-handeling op stuk loopt — kost je adoptie, kwaliteit en eventueel personeelsbinding.