Do You Actually Need a Mobile App? The Honest Decision Guide

Most businesses build mobile apps they don't need

Here's the uncomfortable truth: a significant portion of business mobile apps never gain traction, get abandoned within months, or could have been better served by a responsive website.

But some businesses genuinely need mobile apps. The app becomes their primary product, competitive differentiator, or essential customer touchpoint.

The trick is knowing which camp you're in before spending £50k+ on development.

When you definitely need a mobile app

Some scenarios make the mobile app decision obvious.

The app IS your product. If you're building Uber, Deliveroo, or a mobile game, you need a mobile app. Fairly self-explanatory.

You need native device features. Camera access, GPS tracking, push notifications, offline functionality, sensor data—these require native capabilities that websites can't match (or can't do well).

Users need frequent, quick interactions. If your product is something users open multiple times daily for brief sessions, an app's immediate accessibility beats a website.

Offline functionality is critical. Field workers, remote locations, areas with poor connectivity—if your users can't rely on internet access, you need offline capability.

You're building for specific mobile-first markets. Some demographics and geographies are mobile-only. If that's your market, meet them where they are.

When you probably don't need a mobile app

Other scenarios seem to demand apps but really don't.

Your website traffic is 70%+ mobile. This alone doesn't justify an app. It justifies a responsive website. Build that first.

You want push notifications. Web push notifications work on Android. For iOS, you can use SMS or email. Don't build an entire app just for push.

Everyone else in your industry has an app. Herd mentality isn't strategy. If competitors' apps have terrible reviews and low usage, learn from their mistake.

You think it will increase engagement. Apps don't magically create engagement. If your website doesn't engage users, an app won't either.

You want to be "innovative." Apps aren't innovative anymore. They're a mature technology. Build one if it serves users, not to seem cutting-edge.

The progressive web app (PWA) middle ground

Before jumping to native apps, consider whether a PWA solves your problem.

What PWAs can do:

• •Install to home screen like an app
• •Work offline with service workers
• •Send push notifications (Android)
• •Access camera, location, sensors
• •Provide app-like navigation and UX
• •Update instantly without app store approval

What PWAs can't do as well:

• •Deep integration with device features
• •Background processing
• •Push notifications on iOS
• •Appear in app stores
• •Sophisticated offline data sync

When PWAs make sense:

You need some app-like features but not full native capabilities. You want faster time to market. You want a single codebase for web and mobile. You don't want ongoing app store management.

Many businesses should try PWA first, graduate to native app only if limitations become real blockers.

React Native vs Native: The real tradeoffs

If you've decided you need a native app, the next question is whether to build truly native (Swift/Kotlin) or use React Native.

React Native advantages

Single codebase for iOS and Android. Write once, deploy to both platforms. This is the main selling point. Roughly 70-80% code sharing in practice.

Faster development. One team building one codebase is faster than two teams building separate apps. Time to market can be 30-40% faster.

Web developer skills transfer. If your team knows React, they can build React Native apps. Hiring is easier.

Faster iteration. Hot reloading and faster build times mean quicker development cycles.

Lower cost. One codebase means lower development cost. Maintenance is cheaper too.

React Native disadvantages

Performance ceiling. For most apps, React Native is plenty fast. For graphics-intensive, animation-heavy, or complex apps, native is faster.

Native features lag. When iOS or Android release new capabilities, React Native support comes later (weeks or months).

Third-party dependency risk. You're reliant on community packages for many features. Quality varies. Maintenance can be spotty.

Debugging complexity. Issues that cross the JavaScript-native boundary can be painful to debug.

Not truly universal code. Despite marketing, you'll write platform-specific code for many features. It's less than full native, but not zero.

Native advantages

Maximum performance. You're using the platform's tools and languages directly. No performance overhead.

Full platform capabilities. Immediate access to every OS feature the day it launches.

Better tooling. Xcode and Android Studio are mature, powerful development environments.

Predictable behaviour. No abstraction layer means fewer surprises and weird edge cases.

Future-proof. You're building with the platform's native tools. No risk of framework abandonment.

Native disadvantages

Separate codebases. iOS and Android teams building in parallel. More expensive, slower, harder to keep in sync.

Specialized skills required. Swift and Kotlin developers are more expensive and harder to find than JavaScript developers.

Slower iteration. Build times are longer. Testing cycles take more time.

Higher ongoing cost. Maintaining two separate codebases indefinitely costs more.

The decision framework

Here's how to choose:

Choose React Native when:

• •Budget is limited (under £100k for initial development)
• •Time to market is critical
• •Your team knows React already
• •The app is content-focused (social, e-commerce, news)
• •You need feature parity across platforms
• •Performance requirements are standard

Choose Native when:

• •Performance is critical (games, AR/VR, complex animations)
• •You need cutting-edge platform features immediately
• •Budget supports two development teams
• •You're building for one platform primarily
• •Your team has strong native expertise
• •You need maximum reliability and performance

Choose PWA when:

• •Your main use case is accessing content/services
• •Users don't need frequent interaction
• •App store presence isn't critical
• •You want faster time to market
• •Budget is constrained
• •You're testing demand before committing to native

The cost reality

Let's be specific about what these choices cost.

Simple PWA: - Development: £15k-30k - Ongoing: £2k-5k annually - Timeline: 2-3 months

React Native app: - Development: £40k-80k - Ongoing: £8k-15k annually - Timeline: 3-5 months

Native app (both platforms): - Development: £80k-150k - Ongoing: £15k-30k annually - Timeline: 4-8 months

These are ballpark figures for standard business apps. Complex apps cost significantly more. Simple apps can cost less.

The ongoing costs include bug fixes, OS updates, security patches, and minor feature additions. Major features are additional.

Beyond development: The hidden costs

Building the app is only the beginning.

App store fees: £99/year for Apple. £25 one-time for Google.

App store optimization: Getting discovered in app stores requires ongoing effort. Budget £500-2k monthly if this matters.

Push notification services: Platforms like OneSignal, Firebase have costs that scale with usage. Start at £0-50/month, can reach hundreds at scale.

Backend infrastructure: Your app needs servers, databases, APIs. Cloud hosting starts around £100/month, scales with usage.

Analytics and monitoring: Understanding app usage and catching errors requires tools like Mixpanel, Sentry, Amplitude. £0-500/month depending on scale.

Customer support: Apps generate support tickets. Budget for increased support load.

Marketing the app: Getting downloads requires marketing budget. Organic discovery is brutal in app stores.

The development process

Whether you choose React Native or native, expect this process:

Discovery and planning (2-4 weeks): - Requirements documentation - User flow mapping - Technical architecture decisions - Design system creation - Project scoping and estimation

Design phase (3-4 weeks): - Wireframing - Visual design - Prototype creation - User testing - Design iteration

Development (8-16 weeks): - Core functionality development - Third-party integrations - Backend API development - Iterative testing - Bug fixing

Testing and refinement (2-3 weeks): - QA testing across devices - Performance optimization - Security review - Beta testing with real users - Polish and refinement

Launch preparation (1-2 weeks): - App store listing creation - Compliance review - Submission to app stores - Marketing material preparation - Support documentation

Total realistic timeline: 4-7 months from contract to launch for a standard business app.

Validating demand before building

Don't commit to full app development without validating demand.

Landing page test: Create landing page describing the app. Drive traffic. Measure sign-up rate. If people won't even enter their email, they won't download your app.

PWA prototype: Build minimal PWA with core features. Test with real users. Measure engagement. If the PWA doesn't engage users, a native app won't magically fix that.

Beta program: Find 20-50 potential users. Build minimal version. Watch how they actually use it. Listen to what they struggle with.

Competitor analysis: Research similar apps. Check download numbers, reviews, ratings. If competitors' apps are abandoned, understand why before repeating their mistake.

Measuring mobile app success

Define success metrics before building:

Acquisition: - App store ranking for key terms - Organic vs. paid downloads - Cost per install - App store conversion rate

Activation: - Account creation rate - Onboarding completion rate - First key action completion - Time to value

Engagement: - Daily/monthly active users - Session length and frequency - Feature usage rates - Retention curves (day 1, 7, 30, 90)

Monetisation (if relevant): - In-app purchase rate - Average revenue per user - Lifetime value - Churn rate

Sentiment: - App store rating and reviews - Support ticket volume - Net Promoter Score - User satisfaction surveys

Set target metrics before launch. If you're not hitting them, understand why before investing more.

Common mobile app mistakes

Learn from others' failures:

Building the app you want, not the app users need. Your assumptions about what users want are probably wrong. Test early and often.

Neglecting onboarding. You get one chance at first impression. Complex onboarding kills retention.

Ignoring performance. Slow apps get deleted. Optimize aggressively.

Requiring account creation too early. Let users experience value before demanding registration.

Notification spam. Aggressive push notifications lead to app deletion and bad reviews.

Ignoring platform conventions. iOS and Android have different design patterns. Respect them or confuse users.

Treating the app as finished. Apps need ongoing development. Plan for continuous improvement, not one-and-done.

Getting help with the decision

Sometimes you need external perspective.

Consult experts when: - You're unsure whether you need an app at all - Technical tradeoffs are unclear - Cost estimates vary wildly - You lack in-house mobile expertise - The decision represents significant investment

Red flags in consultants: - "You definitely need an app" before understanding your business - Pushing their preferred technology regardless of fit - Unable to articulate tradeoffs clearly - No interest in validating demand first - Vague timeline and cost estimates

Good consultants explore whether you need an app, help you validate demand, recommend appropriate technology, and give realistic timelines and costs.

The bottom line

Most businesses should:

1. 1.Start with a responsive website that works brilliantly on mobile
2. 2.Consider PWA if you need some app-like capabilities
3. 3.Build native app only when clear use case justifies it
4. 4.Choose React Native unless performance or cutting-edge features demand native
5. 5.Validate demand before committing to full development
6. 6.Plan for ongoing development and maintenance, not one-time build

Mobile apps can be transformative for the right businesses. They can also be expensive distractions for businesses that didn't need them.

Be honest about whether you're solving a real user problem or building an app because everyone else has one.

Your users (and your budget) will thank you.

---

Need help making the call?

We help businesses evaluate whether they need mobile apps, choose the right technology approach, and build apps that users actually adopt.

[Get in touch](/contact) for a free consultation on your mobile strategy.