Mobile apps for B2B SaaS products

Pick the jobs that belong on a phone

Four kinds of work earn a mobile app in a B2B product. Capturing something at the moment it happens, away from a desk. Approving something in under a minute. Being told something that can't wait. And looking one fact up while standing in front of the person who asked.

A useful test: would you do this standing up, holding a coffee, with one hand? If not, it belongs on the web app, and putting it on the phone anyway produces a worse version of something the browser already did well.

The temptation is a full port, because it sounds complete and demos well. It's also the version that costs the most to build, the most to maintain and the least to your users, and there's a second reason it disappoints. Your web product was built for somebody with a keyboard, a big screen and half an hour. The same task on a phone isn't a smaller version of that. It's a different task, done in ninety seconds, wanting fewer fields and a different definition of finished.

How to cut a mobile scope out of the web product

Most mobile scopes start life as a list of screens copied out of the web app, which is why so many of them are too big. Start from where the work happens instead.

Here's the sequence. You can run it yourself over a couple of afternoons, before you talk to anybody about building it.

1. 1. List the moments, not the screens

   Write down every moment a customer does something for your product away from a desk, in their own words. Signing off a job in a stairwell. Approving a request between meetings. Checking one number in front of the person who asked. A list of moments, not a copy of your navigation.

2. 2. Score each moment on how often and where

   Against each one, put how often it happens and whether a desk was available at the time. Weekly with no desk goes to the top. Monthly at a desk isn't a mobile job, however loudly it gets requested. An afternoon here settles arguments that would otherwise land mid-build.

3. 3. Cut anything a phone does worse

   Anything needing a lot of typing, a side-by-side comparison, or a table wider than a hand belongs on the web. A phone version of those is a worse version, and shipping one teaches people the app isn't where the real work happens. Record each cut with its reason.

4. 4. Find the two jobs that carry the app

   Of what's left, two will account for nearly every time the app gets opened. Usually one capture job and one approval or lookup. Those two get the shortest path from the icon, get designed properly, and get tested on a bad network. The rest is allowed to be plain.

5. 5. Say what happens when a job can't finish

   For each surviving moment, decide what the app does with no signal, with a half-finished form, and with a record somebody else changed first. Answering that for two jobs is one design session. Answering it for twenty is why full ports run long, and it sends most people back a step.

6. 6. Write the release as one sentence

   Something a customer would recognise: an account manager can log a visit and get it approved before they're back at the car. If you can't write that without a list of exceptions attached, the scope isn't cut yet. It's also what you'll check the finished app against.

You can't un-ship a version

This is the real difference from web, and almost every planning mistake in mobile traces back to it. A web fix is live the moment it merges. A mobile fix waits for a review queue, then waits for each customer to decide to update.

The consequences are structural. Your API has to stay compatible with versions you shipped months ago, because they're still out there making requests. New behaviour usually needs a server-side flag so it can be turned off without a release. Anything that could go wrong in a way you can't tolerate needs a forced-upgrade path built in from version one. That's straightforward at the start and awkward in a hurry.

So put two numbers in the plan before anybody starts. How many versions back your API will keep answering, and how long a customer gets after a release before the app insists on updating. Both are ordinary decisions while nothing is wrong, and an argument with a customer's IT department if you're making them during an incident.

Anything you'd normally adjust after launch has to be adjustable without a release, which means the value lives on your server and the app reads it. Copy, thresholds, which features are on, the address it talks to. Decide that later and every small change costs you a submission and a wait.

The network is not a given

Your web users are on wifi at a desk. Your mobile users are in a basement, a stairwell, a van, or a building with thick walls, and that's frequently exactly where the work happens.

So the app has to have an opinion about a write that hasn't landed yet. Capture locally, queue, sync when there's signal, and be honest on screen about which state something is in. Then decide what happens when two people edited the same record from two queues, because that will happen and the default resolution is usually wrong for your business.

Two questions get skipped here and both come back. What happens to a write that's sat in the queue for a week, because somebody captured it and then didn't open the app again. And what happens to it when that person signs out, changes phone or reinstalls. A queue with no answer loses work quietly, and once is enough.

Working offline also means your customer's data is sitting on a phone that can be left in a taxi. Their security review will ask exactly what's on the device and what happens to it when the phone goes missing, and in B2B that review is often what stands between you and a rollout.

All of this is the difference between an app people trust with the record and one they photograph and re-enter later.

Notifications are a budget you spend once

Treat the permission prompt as a single ask, because in practice that's what it is. Asking on first launch, before anyone has seen something worth being told about, spends it on a person with no reason yet to say yes.

That's no longer an iOS-only concern. Since Android 13, Android has required a runtime permission for notifications too, POST_NOTIFICATIONS, and Google's own documentation says that if the user picks don't allow, the app can't send notifications, barring a narrow set of exemptions, and all its channels are blocked. Getting that back means the customer going into system settings and turning you on again themselves.

After that it's about restraint. One noisy week teaches people to swipe your notifications away without reading them, and that habit doesn't come back. Give each type its own switch, default the marginal ones to off, and let the app show anything that isn't time-sensitive when it's opened.

Then be clear about who each notification is for. In B2B the person holding the phone usually isn't the person who bought your product, and anything sent to move your own engagement numbers is the fastest way to get the channel turned off. Send what unblocks somebody. Show the rest when they open the app.

Getting it onto your customers' devices

In B2B the store isn't always the distribution channel. Some customers issue managed devices and want your app pushed through their own device management, some want it locked to their employees, and some run a security review before anything gets installed. That changes the build and the release process, not just the paperwork.

Where it does go through the public stores, we handle submission, the review process and the assets each store wants. Review itself is usually quick. Apple publishes that on average 90% of submissions are reviewed in less than 24 hours. What costs you calendar time is a rejection, because the fix and the resubmission put you back in the queue.

For a B2B app the most common self-inflicted rejection is a login the reviewer can't get past. Apple's App Review Guidelines ask you to include demo account information and to turn on your back-end service if your app includes a login. Nearly every B2B app is entirely behind one, so somebody has to own a working demo tenant and keep it working for every release.

Managed distribution changes the plan more than most teams expect. How the app is signed. Whether it arrives pre-configured with the customer's tenant so nobody types a server address. Whether their staff sign in with the identity they already have. That's a scoping conversation, and it's a bad surprise on release day.

Native or cross-platform, and what actually decides it

This is the first question most people ask and close to the last one that matters. For most B2B products cross-platform is the right default, because the jobs that earn a phone app are forms, lists, approvals and lookups rather than anything exotic. Native earns its cost in specific conditions, and the useful question is whether any of yours are met.

Work through the factors below and see whether they point the same way. One pointing at native against five pointing the other way is usually one feature's problem rather than the whole app's, and it's often solvable inside a cross-platform build.

Two surfaces, one release plan

The expensive mistake is treating mobile as a second product. Different people, a different year, a different set of conventions, and eventually a different name for the same thing on each surface. Reconciling that later costs more than building them together would have.

Mobile makes that harder than web does, because the two surfaces don't ship on the same clock. A change that spans both has an order to it, and the order is always the same. Whatever has to tolerate both the old app and the new one goes out first, and the mobile release follows once that's live. Get it backwards and the web release breaks every phone in the field for as long as the store queue lasts.

When we rebuilt a market-research platform for healthcare professionals, the mobile app and its web counterpart came out of one engagement rather than two. That client sells research rather than software, so what carries over is the shape of the problem and not the market: more than one surface over a single product, and one place where the names for the things inside it get settled.