A browser tab gets closed and forgotten. Your web portal might be the most useful thing your organisation gives its staff, members or patients. But every visit still depends on someone remembering it exists, finding the link and logging in again. That's why more teams are looking at turning their web portal into a mobile app.

It's a quiet cost, and an easy one to miss. The portal works. People use it, and you can see the demand in your analytics. But it can't tap anyone on the shoulder, it stalls without a decent signal, and it lives behind a bookmark most people never saved.

The build is rarely the hard part. The hard part is the meeting where someone says, "We have to show the board exactly what it buys."

This article is written for that meeting. We'll cover what an app really changes and the 5 questions your board will ask. Then we'll share 2 projects where we turned existing platforms into apps people come back to.

What turning your web portal into a mobile app actually buys you

Turning your web portal into a mobile app buys you 4 things: repeat use, reach to people who aren't sat at a desk, a marketing channel you own, and clear data on what's working. Every other line in your business case hangs off those 4.

• Repeat use. An app sits on the home screen and can bring people back with a well-timed notification. A portal waits to be remembered.
• Reach. The people who need your portal most are often furthest from a laptop: sales staff on a shop floor, field teams, patients at home, members on the move.
• Data. An app lets you track whole journeys, not just page views, so you can see which content, features and prompts drive the behaviour you care about.
• A marketing channel you own. Push notifications land on the lock screen for anyone who's opted in, with no inbox filter or social algorithm deciding who sees them. Pair them with in-app messages and targeting based on what people actually do, and you can promote campaigns, launches and offers at the moment they're most relevant, without paying for every impression.

The way people use their phones backs this up. Ofcom's Online Nation 2025 report found that UK adults now spend 4 hours 30 minutes a day online outside work, and that most of that time is on a smartphone. Smartphone users use an average of 41 apps a month. Sensor Tower's State of Mobile 2026 report puts global time in apps at 5.3 trillion hours in 2025, or 3.6 hours per user per day.

For staff and member portals, the reach point is even sharper. Gartner estimates there are around 2.7 billion frontline employees worldwide, more than double the number of desk-based workers. If your portal serves people like that, the phone in their pocket is the only screen you can count on.

That's the real app vs web portal question. It isn't about which is more modern. It's about where your users already spend their time, and whether you're there.

A browser tab gets closed and forgotten

A portal leaks engagement in small ways that add up. Someone gets an email, clicks through, does the task and closes the tab. Next time, they have to remember to come back on their own. Most won't.

An app changes the mechanics of coming back. Here's how the 2 compare on the things that matter most for repeat use:

• Where it lives. Portal: a bookmark, or a link buried in an email. App: an icon on the home screen.
• Bringing people back. Portal: email reminders, and hope. App: push notifications, timed and targeted.
• Patchy signal. Portal: stalls or fails. App: works offline and syncs when back online.
• Signing in. Portal: passwords, often every visit. App: face or fingerprint login, stays signed in securely.
• Device features. Portal: limited, and patchy on iPhone. App: camera, Bluetooth, location, audio.
• What you can measure. Portal: page views and sessions. App: journeys, completions and retention over time.

None of this means your portal was a mistake. It's often the reason you have a case at all. A portal with steady traffic has already proven that people want what you offer. An app turns that occasional visit into a habit.

The wider market is moving the same way. eMarketer's analysis of Sensor Tower's latest data shows app installs flattening while total time in apps and spend per user keep rising. Its conclusion for brands was simple: frequency now beats reach. That's exactly the gap a portal can't close on its own.

"We have to show the board exactly what it buys"

A strong mobile app business case answers 5 questions before anyone asks them. Get these right and the conversation moves from "do we need this?" to "when can we start?"

1. What will it cost, and in what stages? Boards are far more comfortable with phased spend than a single large number. Break the work into discovery, a first release that covers the tasks people use most, and later releases tied to results.
2. What will change for users? Be specific. Not "better engagement", but "staff can finish a training module on the train with no signal" or "patients get a reminder at the moment they need to submit a reading".
3. How will we measure it? This is where most cases fall down. Pull a baseline from your portal now: weekly active users, completion of your 2 or 3 key tasks, time to complete, and support requests. Agree what good looks like at 3 and 6 months after launch.
4. What's the risk? Name it before they do. Delivery slipping, app store rejection, and getting locked into a supplier are the usual worries. Each has a clear answer, and we cover all 3 below.
5. What can we reuse? Usually more than people expect. Your content, user accounts and business logic don't need to be thrown away. Often, the existing backend stays and the app talks to it through an API.

Enterprise mobile app ROI is rarely about a single headline figure. It's about a handful of measurable shifts in behaviour the board already cares about. Think more people completing training, fewer missed appointments, fewer calls to support and better-informed sales staff. Tie each of your app's features to at least 1 of those, and the business case gets much easier to make.

That's why we build analytics in from day 1. If you can't show the board what changed, you'll struggle to fund the next phase.

Proof 1: a staff training portal rebuilt as an app people use

A global consumer electronics brand came to us with a UK staff training portal that was doing its job, but not enough of it. Retail staff used it for quizzes, games, leaderboards and points-based rewards, so gamification was already doing a lot of the work. The brand wanted more of them using it, more often, and better campaign opportunities on top.

We started with discovery workshops to agree what to keep and what to change. The answer was to keep almost everything staff already valued and rebuild the experience around their phones.

We built a React Native app for iOS and Android on top of the existing WordPress and MySQL backend, through a custom REST API. The app kept the quizzes, competitions and rewards, then added:

• Push notifications to bring staff back for new content and campaigns
• Offline support, so modules still work with a weak signal
• Predictive search and text to audio for quicker, easier learning
• Access controls for different retailer groups

We also tightened up the platform underneath with containerised environments, CI/CD pipelines and regression testing, then connected GA4, BigQuery and Looker Studio so the team could see engagement in real time.

In the first 3 months, the app brought in more than 1,000 new sign-ups and higher quiz completion rates. Just as important for the business case, the brand gained clear insight into which content drove participation. That's the kind of evidence that makes the next investment an easier conversation.

Proof 2: Spirit Health and taking the risk out of delivery

Most boards worry about 2 things with a project like this: will it land on time, and will we be stuck with the supplier forever? Our work with Spirit Health answers both.

Spirit Health is a UK healthcare company that helps keep people with long-term conditions out of hospital. We rebuilt their Booking Hub, moving it from an ageing ASP.NET and SQL setup to Next.js and React with MongoDB. We also delivered Clinitouch, their remote patient monitoring app on iOS and Android, which is used across the NHS and in 14 countries.

We took on Clinitouch when it was already behind schedule, and we launched it on time. Along the way, we handled complex Bluetooth integrations with the medical devices patients use at home. That's a clear example of why some portals need to become apps: a browser simply can't talk to that hardware reliably.

The part we're proudest of came at the end. We left the code and documentation clean enough that Spirit Health built its own in-house team around it. That's what avoiding lock-in looks like in practice. You should own what you pay for, and be able to run it without us if you choose to.

Web portal to mobile app: wrap it, rebuild it or go cross-platform?

There are 4 main ways to convert a web app to a mobile app, and they're not equal. The right choice depends on what your users need to do, not on what's quickest to ship.

Progressive web app

A progressive web app is your website with some app-like features, which people can add to their home screen. It's the cheapest route, but you're relying on people to add it to their home screen themselves, and support for notifications and device features is weaker on iPhone. It's a reasonable step, not a destination.

Web wrapper

A wrapper puts your existing site inside an app shell. It's fast, but it carries a real risk. Apple's App Store Review Guidelines say an app must offer features, content and interface that take it beyond a repackaged website. Thin wrappers can be rejected under that rule, and the ones that get through often feel like what they are.

Cross-platform app

Frameworks like React Native, or Ionic with Capacitor, let you build 1 codebase for iOS and Android with true native features: offline mode, push, biometrics and device integrations. For most portal projects, this is the sweet spot of cost, speed and quality. It's the approach behind the training app above, and much of our wider mobile app development work.

Fully native

Separate apps written in Swift and Kotlin give you the most control, at the highest cost. It makes sense when performance or deep hardware access is the whole point of the product, but it's more than most portals need.

Whichever route you choose, you rarely need to start your backend from scratch. A clean API layer lets your new app and your existing portal share the same data and logic, so you're extending what you've built rather than replacing it.

Where to start

If your portal already has regular users, you have the start of a business case. An app gives those users a reason to come back, reaches the people who aren't at a desk, and gives you the data to prove what changed. The 2 projects above show it working in a large retail training programme and in NHS healthcare.

The quickest first step is our Mobile Opportunity Audit. It looks at your portal and how people use it, then shows where an app would make the biggest difference and what to measure. It gives you something concrete to take into the boardroom. Contact us today to get your free audit.

When you're ready to commit, our discovery sprint turns that opportunity into a costed, phased plan your board can sign off with confidence.

FAQs

Can we turn our existing web portal into an app?

Yes. In most cases you can keep your existing backend, content and user accounts, and build the app on top through an API. The work goes into designing the mobile experience and adding the features a browser can't offer.

Is a progressive web app enough?

Sometimes, for simple, occasional tasks. But you're relying on people to add it to their home screen themselves, and notifications and device features are more limited on iPhone. If repeat use matters to your business case, a proper app usually earns its keep.

Will Apple accept our website wrapped as an app?

Not if it's just your website in a shell. Apple's guidelines expect an app to go beyond a repackaged website, and thin wrappers can be rejected. Adding real native features such as offline mode, push and secure login gives an app a much better chance of approval.

Do we need to rebuild our backend?

Usually not. We often add or tidy up an API layer so the app and portal share the same data and logic. You get a better mobile experience without throwing away years of investment.

How do we measure the return on a mobile app?

Take a baseline from your portal before you start: active users, completion of key tasks, time taken and support requests. Then agree targets for 3 and 6 months after launch and build the analytics to track them from day 1.

How long does it take to go from portal to app?

It depends on scope, which is exactly why we start with discovery. A focused first release covering your most used tasks gets you live sooner, with later phases funded by the results.