Mobile apps have a reputation problem. Too many businesses have paid for one and got back something their team ignores and their clients never downloaded. So before talking about what a good mobile app looks like, it’s worth asking whether you need one at all.
The honest case for building one
A mobile app makes sense when one or more of these is true:
Your clients or team need to do something on the go that a website handles poorly. Mobile browsers are capable, but they’re not the same as a native app — offline access, push notifications, camera integration, and biometric login all work better (or only work at all) in a native context.
The experience is central to your product, not just a feature. If the app is how clients engage with what you offer — not just a portal to it — then the quality of that experience directly affects whether they come back.
You’re delivering something time-sensitive. Notifications that actually interrupt, not emails that sit unread. If your business model depends on clients acting quickly, mobile is the delivery mechanism that makes that possible.
If none of those apply, a well-built web app or client portal is usually faster, cheaper, and easier to maintain. We’ll say that plainly.
What most mobile briefs get wrong
The most common mistake is building an app around a list of features rather than a specific moment of use.
A brief that says “we need a dashboard, a messaging tab, a document library, and a settings page” is a feature list. It doesn’t tell you what problem the person opening the app is trying to solve in that moment, on their phone, probably between other things.
The apps that get used are the ones that do one or two things exceptionally well. The apps that get deleted are the ones that try to be a full web platform squeezed into a smaller screen.
The right starting question is: what is the one thing someone needs to do in 30 seconds that would make this worth keeping on their phone? Everything else is secondary.
Where AI changes the calculation
AI doesn’t make a badly scoped mobile app good. But it does change what’s possible when the scope is right.
A field service app that can summarise a client’s history before a technician walks in the door. A sales tool that drafts follow-up notes from a voice memo recorded between meetings. A client-facing app that answers account questions from your actual data rather than a generic FAQ.
These aren’t demos — they’re integrations that require your systems, your data, and AI that knows the context. Built properly, they turn a mobile app from a convenience into something that changes how your team works.
What to expect from the build process
A mobile app that’s worth having typically takes longer than clients expect and less time than they fear. The variables that matter most:
- How narrow the brief is — the clearer the core use case, the faster and cheaper the build
- Your existing systems — apps that connect to live data need integration work; that’s where most of the complexity lives
- One platform or two — iOS and Android can largely share code, but each has its own review and submission process
A discovery phase before committing to a full build is almost always worth it. It’s where the brief gets honest — where “nice to haves” get separated from what people will actually open the app for.
The question worth sitting with
If your clients or team had a well-designed app for your business on their phone, what would they actually open it to do?
If you have a clear answer to that, you probably have a viable mobile project. If the answer is “a bit of everything,” that’s the problem to solve first.