The question nobody asks first.
Before anyone starts talking about iOS versus Android, React Native versus Flutter, or whether to list on the App Store or Google Play, the real question is simpler: why does this need to live on a person's phone rather than in their browser?
That sounds obvious, but it's genuinely the thing most agencies skip — because their incentive is to sell you the build, not to talk you out of it. I've turned down app projects because the client needed a better website and some Google Business Profile work. That's not a heroic stance; it's just being straight with people. If what you actually need is a decent mobile-responsive site with online booking, building a native app first costs you six to eighteen months and a five-figure budget before you've even confirmed the market wants what you're selling.
When an app genuinely earns its keep.
There are a handful of signals that suggest an app might be the right call, and they tend to cluster together rather than appear alone.
The first is repeat, habitual use. If your customers are likely to open something more than a couple of times a week, native apps have a real advantage — they're faster to access, they sit on the home screen as a reminder, and they can use push notifications without the user having to remember a URL. A loyalty scheme for a Canterbury coffee shop, a daily check-in system for a fitness studio, a job-tracking tool for a trade team going out to multiple sites each morning — these all have the right usage pattern.
The second is offline functionality. If someone needs to use your product without a reliable data connection — a surveyor noting defects in a basement, a delivery driver marking off drops in a rural part of east Kent with patchy signal — a native app can cache data locally and sync when back online. A website can't do that, at least not without significant extra engineering.
The third is device hardware. If you need the camera for document scanning, the GPS for live location tracking, or local notifications that fire based on time or place, you're into territory where a native or near-native app pays for itself. A website can access some of these features these days, but the experience is still noticeably weaker.
When an app is the wrong answer.
Most small business ideas that come to me as app requests are actually website ideas in disguise. A service directory, a quote request form, an online shop, a booking system for treatments or classes — all of these work perfectly well as responsive websites, and they cost a fraction of the price to build and maintain.
Consider what a native app actually requires from a customer: they have to find it (App Store or Google Play), download it, give it permissions, and remember they installed it. The drop-off at each of those steps is significant. For a one-off or low-frequency interaction — booking a window cleaner in Deal, ordering flowers for a local delivery, enquiring about a skip — nobody wants to download an app. They want to tap the Google result, see the price, and pay. That's a website job.
I've also seen businesses get talked into apps when their real problem was something else entirely: not enough Google visibility, a confusing booking process, no way to take payment online. An app doesn't fix any of that. It just adds a new, expensive layer on top of an unresolved problem.
What things actually cost, realistically.
A simple native app — one platform (Android or iOS), a handful of screens, basic user accounts, and a connection to a backend — starts at around £8,000 to £12,000 done properly. That's a minimum viable build, not something polished with animations and onboarding flows. If you want both platforms from day one, or anything beyond the basics, you're looking at £15,000 to £25,000 before you've marketed it to a single person.
There are ways to reduce that. Cross-platform frameworks like React Native or Flutter mean you write most of the code once and deploy to both iOS and Android, which cuts cost compared to two fully separate builds. Progressive Web Apps (PWAs) sit somewhere between a website and a native app — they install from the browser, work offline, and can send push notifications, though with some limitations on iOS in particular. For some use cases, a PWA hits the sweet spot: cheaper to build than a native app, more capable than a plain website.
I tend to suggest clients budget for ongoing costs too: App Store and Google Play developer accounts (£25 one-off and £79 per year respectively as of early 2026), hosting for the backend API, and the time to push updates when Apple or Google change something under the bonnet. Apps are not a build-and-forget asset in the same way a simple website can be.
The sequencing question.
Even when an app is clearly the right destination, I usually advise proving the core proposition first with something cheaper. Build the web version, or even a manual process, and get twenty or thirty paying customers through it. You will learn things about how people actually use your product that no amount of planning would have told you — and those learnings will make the app significantly better when you do build it.
I went through this myself on one of the businesses I've built. We were convinced we needed certain features in the mobile experience. We were wrong about two of them and had missed one entirely. Finding that out before the build saved a material amount of money and produced something customers actually used rather than something we'd imagined they'd use.
The other reason to sequence carefully is that the App Store review process takes time. Apple's review can take anywhere from twenty-four hours to two weeks, and if they reject something — which they will, at some point — you are waiting again. Planning a product launch around an app approval date is a reliable way to have a bad time. Having the web version live and working means the launch is never held hostage by a reviewer in Cupertino.
What to bring to the first conversation.
If you're considering an app and want to talk it through properly, the most useful things to know before that conversation are: how often your customer would open it, what it would let them do that they cannot do today, whether it needs to work offline, and what your rough budget ceiling is. Those four things tell me almost everything I need to give you an honest steer rather than a broad estimate.
You don't need a specification document or wireframes. A napkin sketch and a clear description of the problem you're solving is plenty. Half the value of an early conversation is working out whether you've correctly identified the problem in the first place.
The bit people don't want to hear.
Apps are genuinely exciting to think about, and I understand why business owners gravitate towards them. There's something tangible about an icon on a phone screen — it feels real in a way that a website doesn't always. But the businesses I've seen get the most traction from apps are the ones that treated the app as a solution to a specific, proven problem with a known customer who already exists. Not the ones that built an app hoping it would create the market.
If you're still early — still working out who the customer is, still testing whether people will pay — the app can wait. Get those fundamentals right first. The technology is the easy part, honestly. It's the market that's hard.