You Probably Don’t Need an App — Unless You Need One of These Four

Plenty of apps get built because a competitor has one. The ones that pay for themselves solve a problem a website structurally cannot.

Let us start with the unusual bit: most small businesses do not need a mobile app, and an agency that tells you otherwise before asking what your problem is should worry you.

A customer will not download an app to buy from you once a year. They will not download an app to check your opening hours. For most businesses, a fast mobile-friendly website does everything an app would, without the download barrier, the app store approvals, or the ongoing maintenance.

But there are four situations where an app is not a vanity project — it is the cheapest way to fix something genuinely broken. If you recognise your business in one of these, the maths changes completely.

1. Your team is running operations on paper, WhatsApp and memory

This is the most under-appreciated use of an app, and usually the highest return. Not a customer app — an internal one.

Think about how work actually moves through your business. A job comes in. Someone has to assign it. The person doing it needs the address, the spec, the customer’s phone number, the site photos. When they finish, someone needs to know, and someone needs to invoice. If that entire chain lives in a group chat and a spreadsheet, you are losing hours a week to admin and losing jobs to things falling through cracks.

An internal operations tool — job assignment, status updates, photo upload from site, sign-off — collapses that into something everyone can see. The return is not glamorous. It is measured in hours nobody has to spend chasing.

Worked example

One of our clients needed enquiries from multiple websites to reach the nearest available installer instantly, rather than sitting in an inbox until someone noticed. Automating that single handoff saved hours daily and cut their response time to minutes — and being first to respond is frequently what wins the job.

They built us an automated lead system that captures enquiries from multiple websites and assigns them to the nearest available installer instantly. It saves us hours every single day and our response time has never been faster.

— James Adkins, COO

2. Customers interact with you frequently and repeatedly

Frequency is the test. If a customer engages weekly — ordering, booking, tracking, checking a balance, following a project — an app earns its place on their home screen. If they engage twice a year, it does not, and it will be deleted in the first storage cleanup.

Where frequency exists, push notifications become genuinely valuable rather than annoying. A notification that says “your delivery arrives tomorrow between 9 and 11” is useful. A notification that says “we miss you!” is why people turn notifications off.

3. You need something a browser cannot do well

Camera-heavy workflows. Offline access on sites with no signal. GPS and route tracking. Barcode and QR scanning. Background location for delivery tracking. Biometric login. These are all things a native app handles smoothly and a website handles awkwardly or not at all.

If your workflow depends on one of these, that is a real technical reason, not a preference.

4. You are testing a new business idea and need to move fast

An MVP — a deliberately minimal first version — exists to answer one question: will people actually use this? Built properly, it is small, cheap and disposable. Built as “version one of the full vision”, it is expensive and slow, and you learn the same thing six months later for ten times the money.

The discipline is choosing the single feature that tests the idea and shipping only that.

Native, cross-platform, or neither

The part everyone forgets to budget for

An app is not finished at launch. Apple and Google update their operating systems on a schedule. Devices change. Libraries get deprecated. An app nobody maintains stops working within about eighteen months, and by then the original build knowledge has evaporated.

Budget for the whole life of the thing: bug fixes, performance monitoring, feature updates, OS compatibility checks. Not because it is expensive — it usually is not — but because an app that stops working is worse than no app at all. Customers who downloaded it and found it broken now have a specific bad opinion of you.

How to decide in five minutes

Write down the single problem you want the app to solve, in one sentence, without using the word “app”. Then ask whether a better website, an automated follow-up sequence, or a chatbot solves that same sentence.

If one of them does, do that instead — it will be faster and cheaper. If none of them does, you have found a real use case, and it is worth building properly.