Customer portal: app or responsive website?

The question behind the question

"Should our customer portal be an app or a website?" is almost never the question you really need to answer. The question underneath is: what do our customers do in that portal, how often do they do it, and what should happen when they do it on a poor connection, in a hurry, or without deliberately choosing to log in?

An insurer with a claims portal has a different profile from a contractor with an employee portal or a hosting provider with a customer dashboard. Some customer portals are checked once a quarter; others are opened ten times a day. Some only need a form and a PDF; others want camera uploads, location data or biometric login. The right solution follows from the profile, not from a wish to "have an app too because the competitor has one".

Three technical forms

Before we go through the criteria, three definitions that are often used interchangeably:

Responsive website

A website that works on desktop, tablet and phone through the browser. The user logs in at a URL, does what they need to do and closes the tab. No installation, no App Store, no separate build per platform. Under the hood this can be a server-rendered site, a Single-Page Application or a hybrid; for the user it makes no difference. See also our deeper explanation of building a Single-Page Application as an alternative within the web category.

Progressive Web App (PWA)

A PWA is a website that behaves like an app: it can be installed on the home screen, works partly offline via a service-worker cache, can receive push notifications (fully on Android, on iOS since iOS 16.4 with limitations) and has its own icon. But it is not distributed through the App Store or Google Play; the user installs it from the browser. A middle ground that suits some scenarios better than the other two. We have a separate guide on this: what is a Progressive Web App vs native app.

Native app

A true native app is built in Swift or Kotlin (or in a cross-platform framework such as Flutter, React Native or .NET MAUI) and distributed through the App Store and Google Play, or via Mobile Device Management for business distribution. It gets deep access to device features, runs in the background, integrates with system-level push notifications and can invoke biometric authentication.

The three forms are not cells you are locked into for ever. You can start with a responsive site, add a PWA layer later, and only build a native app once the numbers justify it. Ownership of data and logic stays with you; only the shell changes.

Criterion 1: frequency of use

The heaviest predictive factor. How often per day, week or year does an average customer open the portal?

Customer portals that users visit monthly or less often (retrieving an invoice, submitting a form once a quarter, viewing a policy) almost always fit a responsive website best. The barrier to installing an app first becomes too high at such a low frequency; customers prefer to log in from an email link or a search result. App installs that are deleted again after three uses are a budget leak you don't see but do pay for.

Customer portals that users visit weekly, such as a supplier portal for purchasing, an employee portal for expense claims or a dealer portal for orders, sit in the PWA zone. High enough to make "installing" worthwhile, not high enough to justify the App Store costs of a native app. A PWA on the home screen feels to the user like an app, without you maintaining two native codebases.

Client portals that users visit daily or several times a day, such as a logistics portal for drivers, a service portal for engineers, or a patient portal for chronic care, are seriously worth considering as a native app. At that level of frequency, on-device performance, background sync, push reliability and biometric login weigh heavily enough to justify the additional maintenance cost.

Criterion 2: Offline mode

Do your users regularly work in places with poor or no network coverage? A field engineer in a boiler room, a driver in a tunnel, a nurse in a hospital with dead zones, an inspector at a remote site: if "no network" is a daily scenario, a responsive website is not an option. A browser tab doesn't work without a connection (apart from whatever happens to be in its cache).

A PWA can provide an offline layer with a service worker: cached screens remain available, and forms can be stored and synchronised once the connection returns. For light offline scenarios, that is enough. For heavy offline scenarios, such as a work-order app that must function for hours without a connection, with conflict resolution when two engineers edit the same order, you need the database control of a native app: local SQLite or a sync engine such as WatermelonDB or Realm, with background sync via OS-level scheduling.

The rule of thumb: offline periods measured in minutes mean a PWA will do. Offline periods measured in hours or days mean a native app.

Criterion 3: Push notifications

Push is a discipline in its own right. A responsive website cannot technically send push notifications; for that you need at least a PWA (on Android for some time now; on iOS since 16.4 in 2023, with limitations around installed web apps). A native app gets full access to the notification system, including rich notifications, action buttons, geofencing triggers and background categorisation.

How critical is push for your portal? A few examples from practice:

• Critical: a care portal that alerts a patient when it is time to take medication. If they miss the push, harm can follow. Native app, possibly with the critical alerts permission on iOS.
• Important: a service portal that pushes a new job to an engineer as soon as it comes in. A missed push means a missed appointment; a native app or a well-functioning PWA will do.
• Nice to have: a client portal that sends a reminder once a quarter to submit a form. Email can do that too; a responsive website with an email trigger is sufficient.

The mistake we see most often: a client says "push is important" because it goes with an app, while the usage profile shows that email or SMS would work just as well. Push costs you an app project; weigh it on real impact, not on a default assumption.

Criterion 4: Hardware access

Which device features do you need from the portal? Browser APIs have become powerful in recent years, but there remain gaps where only a native app is the solution.

Camera

The browser can now take and upload photos on all modern phones. For a damage-reporting portal or a PIM portal with product photos, that is enough. What the browser cannot do: real-time AR overlays, advanced scanning modes for barcodes or QR codes in low light, or camera access in the background.

GPS and location

The browser can obtain location, but only while the tab is active. Background location, for example to automatically log working hours on arrival at a client's address, or for geofencing notifications, only works in a native app with the appropriate permissions.

Biometrics

Face ID and Touch ID can be triggered in a browser via the WebAuthn standard, but the user experience is rougher than in a native app. For a portal where biometric login is a daily action, such as a banking app, a healthcare portal with patient data, or an insurance portal with case files, a native implementation feels considerably more natural.

NFC, Bluetooth, sensors

NFC for card readers, Bluetooth for IoT integration with measuring equipment, accelerometer for step counting: these are almost exclusively native. Web Bluetooth exists but doesn't work on iOS Safari, and coverage on Android is fragmented.

Criterion 5: branding and experience

A native app gets its own place on the home screen, its own splash screen and its own app switcher card. To the user, it feels like a standalone product. For brands that want to strengthen their customer relationship, such as premium service providers, subscription models and long-term relationships, that carries value you do not get in a browser tab.

A PWA comes fairly close: an icon on the home screen, full-screen mode, a custom splash screen and custom colours. For most branding goals that is enough, and on iOS Safari the difference between an installed PWA and a native app is not noticeable to the average user.

A responsive website gets lost among the browser tabs. It has no branded environment, no splash screen and no background presence. That is not a problem for portals whose value is purely transactional (retrieving an invoice, submitting a form), but for portals where engagement is the desired outcome, it is a cost in user experience.

Criterion 6: SEO and findability

This is where the trade-off turns. A customer portal behind a login should stay out of search engines; that is a security requirement, not an SEO goal. However, the marketing pages that lead to the portal must be findable: an explanatory page, an onboarding flow and, where relevant, a demo account.

A responsive website integrates with this effortlessly: the same tech stack, the same URL structure and the same SEO approach. The marketing page appears in Google, the user clicks through, logs in on exactly the same site and lands in their portal. No context switch, no duplicate branding.

With a PWA this also works: a PWA is by definition a website, with the added option of installation. The marketing page and the installable app share a URL base and analytics.

A native app requires a separate marketing funnel: a landing page aimed at App Store installation, App Store Optimisation, and analytics attribution to learn which campaign produced which install. Not impossible, but it is a second discipline on top of what you already do for the website.

Criterion 7: GDPR and EU data residency

A customer portal almost always processes personal data, and in many cases special category personal data (health, finances, identity). This brings GDPR obligations that apply regardless of platform, but which play out differently for an app than for a website on a number of points.

The website and the app share the same fundamentals: a lawful basis for processing, data minimisation, security in line with the state of the art, Data Processing Agreements with sub-processors, a mechanism for access and erasure requests, and reporting data breaches to the Dutch Data Protection Authority (Autoriteit Persoonsgegevens) within 72 hours.

EU residency of data is a recurring point: many business customers require that their customer data remains within the EU and is not subject to non-EU jurisdictional requirements such as the US CLOUD Act. In practice this means hosting with an EU cloud provider, EU regions with hyperscalers or, in some sectors, a private cloud. That choice applies to your backend, and choosing an app or a website changes nothing there, since both communicate with the same API and the same database.

Where it does differ: the app brings in an extra player, namely Apple or Google. A native app has to comply with the App Store Review Guidelines and Google Play Policies, which layer their own privacy requirements on top of the GDPR (privacy labels, app tracking transparency, opt-in for identifiers). For a portal handling sensitive data, that is a second compliance stack you have to work through. Not insurmountable, but it does take effort. A responsive site or a PWA bypasses this stack entirely.

The European Accessibility Act (EAA) and WCAG 2.2 apply from 28 June 2025 to commercial digital products, and the guidelines cover both websites and apps. A customer portal for a major service provider has to meet WCAG, whether it runs in a browser or as an app. If you are still building without an accessibility baseline, you are building for a rebuild.

Criterion 8: long-term ownership

Who will still own the code, the data and the relationship with your customers in five years' time?

With a responsive website and a PWA, the answer is clear: you. Your own domain, your own hosting, your own codebase, your own analytics. No intermediary that can change its policy at any moment or close your accounts.

With a native app, Apple and Google become permanent intermediaries in the chain. They can remove your app from the Store if they judge it to breach a (new) guideline, change their commission rates, or impose technical requirements you did not anticipate. In practice these platforms are predictable enough to build a product on, but anyone who wants to be "in control of every aspect" yourself is working around this dependency.

The same applies to cross-platform frameworks: Flutter is Google's, React Native is Meta's, and .NET MAUI is Microsoft's. You are dependent on their roadmaps. For a fuller look at what ownership means for budget and risk, see our guide to custom software costs, which covers total cost of ownership over a multi-year project.

When to choose a responsive website

The responsive website choice is defensible in these profiles:

• Customers visit the portal monthly or less often. An app installation would be a wasted barrier for most of them.
• The content is mainly documents, forms or dashboards. No camera overlay, no background location, no daily biometric login.
• The portal needs to work across a wide range of devices: office desktop, older work laptop, smartphone, tablet. One codebase that works everywhere, rather than two native builds plus a web fallback.
• Findability matters: part of the portal, or the sales journey leading to it, needs to appear in search results.
• You want to go live faster than a double build cycle allows. Web deployment is a direct push to production; app distribution waits for store review.
• Long-term ownership and independence from platform policies weigh heavily.

Concrete examples from our practice: an insurer with a policy portal for consumers, an accountancy firm with a client dashboard for annual accounts, a property manager with a tenant portal for repair reports. All are portals where users log in anywhere from a few times a year to a few times a month. An app would cost money without increasing the value to the user.

When to choose a PWA

The PWA wins mainly when you have weekly usage, push is desirable, and you want to avoid the App Store overhead. Specifically:

• Customers use the portal weekly to a few times a week. Enough to make "installing" worthwhile; not enough to justify two native codebases.
• Push notifications are useful but not critical. The PWA pushes well enough. Only more advanced push functionality (geofencing, critical alerts) remains out of reach.
• A light offline mode is enough. If the connection drops, the portal should still be able to display a few screens and save forms for later synchronisation.
• You don't need deep hardware features: photo upload from the camera, yes; background camera access, no. Location while the tab is active, yes; geofencing, no.
• You don't want to go through App Store review for every small update. A PWA gets updates the moment you publish it, with no review waiting time.
• Distribution via your own URL or a QR code is viable for your target audience, with no App Store discovery needed.

In practice: dealer portals for purchasing, supplier portals for work in progress, and B2B customer portals where a fixed group of users works with the app. For a deeper look at the PWA choice, we have a separate guide on the comparison between PWA and native app.

When to choose a native app

There are scenarios where neither a PWA nor a website can handle the volume that a native app solves. The most demanding are:

• Daily or multiple-times-a-day use by the same group. An app on the home screen significantly lowers the barrier to repeated use.
• Heavy offline mode: users must stay productive for hours or days without a connection, with local data storage, conflict resolution and background sync.
• Critical push: missing a notification causes harm to the end user (healthcare, safety, logistics with SLA requirements).
• Deep hardware access: background GPS, NFC, Bluetooth pairing with IoT equipment, AR overlay on the camera, biometric daily login.
• A premium brand experience: the portal is part of a brand experience where having its own space on the device adds value.
• Distribution runs through the client's Mobile Device Management: an employer installs the app on its employees' managed devices. A PWA works there too, but it feels different from an MDM-managed app suite.

Concretely: a service app for engineers, an employee portal for daily use (see our page on building an employee portal for the wider context), a patient app with medication alerts, and a driver app for logistics planning. For the broader picture of when an app makes sense at all, see our main page on app development.

A hybrid strategy

The three forms are not mutually exclusive. In fact, for many customer portals a phased strategy is the best route.

Start with a responsive website. That is almost always the first building block: the marketing pages and the portal features share a URL base, codebase and branding. It goes live faster and costs less to maintain than a duplicate app build.

After a few months of real-world use, add a PWA layer if the figures show that customers return weekly or more often. Service worker, manifest, installability, basic push. That is an extension of the existing codebase, not a rebuild.

Only build a native app when the PWA figures hit a ceiling: daily use by a large group, hardware features you cannot access in the browser, push that becomes more critical, or explicit enterprise deals that require "a real app" as a requirement. At that point the back end is mature, you know which features are genuinely used, and you build a shell optimised specifically for those.

The phased approach avoids the classic failure pattern: a first native app version that is empty on day one, has no users and generates no feedback, while a team of native developers creates monthly costs that the project has to carry. Start lean and scale on what genuinely gains traction.

Frequently Asked Questions

Does GDPR work differently for an app than for a website?

The material requirements (lawful basis, data minimisation, security, transparency) are identical. What differs: an app brings Apple and Google in as a second compliance layer, with their own privacy policies and data-handling requirements that sit alongside GDPR. A website avoids that layer.

Does the European Accessibility Act apply to customer portals?

Yes. From 28 June 2025, commercial digital products and services fall under the European Accessibility Act (EAA), and that covers both apps and websites. WCAG 2.2 at level AA is effectively the baseline in practice. For business portals built for a single client, the direct obligation is narrower, but accessibility-by-design is the direction all legislation is moving in regardless.

Can a PWA on iOS do as much as on Android?

Almost, but not quite. Since iOS 16.4 (early 2023), Safari supports installed PWAs with web push, but the advanced push features (rich media, action buttons, geofencing) are more fully supported on Android. If your PWA strategy relies heavily on iOS users, it is worth mapping out the iOS-specific limitations upfront.

What about App Store commissions for a customer portal?

Apple and Google charge a 15 to 30 per cent commission on in-app purchases and subscriptions. For a customer portal that does not process consumer payments within the app, such as an employee portal, a supplier portal, or a B2B client dashboard without transactional payments, this does not apply. It becomes relevant once you let consumers pay directly within the app.

Is a PWA SEO-friendly?

A PWA is a website with an extra layer, and its public pages are indexed like any other. Behind the login, SEO plays no role, which is by design. The marketing layer of a PWA works identically to a regular responsive website from an SEO perspective.

Can we switch from a responsive site to an app later?

Yes, and for many customer portals that is the smartest route. The back end (API, database, business logic) stays the same; only the shell is added to. The web functionality does not need to be discarded. It remains available for customers who do not want to install an app or who prefer working in the browser.

How much does it cost to build an app or portal?

It depends on scope, integrations and requirements around offline use, hardware and multi-tenancy. A simple client portal with a few forms and a document archive is a different project from a portal with multi-tenancy, SSO, audit logging and real-time integrations with an ERP. After an introductory call, we give an indication based on your specific profile.

Does the choice still matter if the user cannot influence the decision themselves?

Yes, and that is exactly when it matters most. An employee portal or supplier portal that your staff are required to use directly affects their working experience. A poorly chosen format, such as an app with no room to get through a task, or a website where a key offline action breaks down, will cost you adoption, quality, and possibly staff retention.