Mobile apps people actually open — what we learned

Building a mobile app is one of the easiest ways to spend a six-figure sum and end up with something nobody opens twice. We’ve shipped a handful of mobile companion apps for client SaaS products — including the new mobile app for LunaHR — and the lessons are mostly about restraint, not engineering.

The first question: do you even need an app?

For a lot of business products, the honest answer is no. A well-built responsive web app, installable as a Progressive Web App, will do everything the user actually needs and saves you the cost and friction of two separate codebases. The cases where a native app is genuinely worth it are narrower than vendors will admit:

• The user reaches for it in contexts where the web is awkward. One-handed on a shop floor, on the move, with patchy connectivity, in a uniform pocket.
• The app needs hardware capabilities the web can’t reach reliably. Background location, sustained Bluetooth, secure biometric unlock, native camera scanning, push notifications that actually arrive.
• The brand expectation demands it. Sometimes “there’s an app for that” is part of the credibility story you’re selling, fairly or not.

If none of those apply, save the budget.

If the answer is yes, build the right shape

Companion apps for B2B products almost never need feature parity with the web. The usage profile is fundamentally different. The web is where you set things up, configure, report, audit. The app is where you do the five or six things that make sense to do on the move.

For LunaHR, that’s things like submitting an expense by photographing a receipt, requesting time off, approving a request from a notification, and checking in or out an IT asset by scanning a QR code. The depth of the web product is intentionally not in the app. The job of the app is to make the on-the-move tasks frictionless.

Push notifications are a privilege, not a feature

Two badly-timed pushes and the user disables them. Three more, and they delete the app. Treat push notifications like email marketing — earn each one, segment carefully, and let the user shape what they receive. The default configuration should be conservative; the power users will turn more on.

Offline behaviour is the differentiator

Most B2B apps fall over the moment the network does. The ones people love work offline-first: actions queue locally, sync when connectivity returns, and surface conflicts in a way that doesn’t lose the user’s work. This is harder than it sounds and is the single area we put the most engineering investment into.

Cross-platform vs native

Our default is React Native (or Expo) for almost all client work. The reasoning is pragmatic: shared code with the web React app, a single team, faster iteration, and the platform-specific gaps that mattered five years ago have largely closed. The cases where we still recommend pure native are narrow — usually heavy graphics, deep integration with specific OS features, or regulated industries where the platform-specific UI requirements are non-trivial.

Ship the smallest possible app first

The single biggest mistake we see in mobile briefs: trying to launch with a feature-complete app. Don’t. Ship the three highest-value mobile workflows, get them in users’ hands, watch what they actually do, and build version two from real data. Apps are easier to expand than to right-size.