Probably not. We build them, so that's worth saying clearly before anything else.
Most businesses that ask for an app are actually asking for something narrower: a way for customers to book without calling, a way to track an order without messaging, a way for staff in the field to report without driving back to the office. Those are real problems. An app is one way to solve them, and frequently not the cheapest or the best.
This guide is the conversation we have before quoting any app project — the three tests that decide whether it should exist, and what to build instead when it shouldn't.
Why businesses want an app
The reasons usually fall into four groups, and only some of them are good.
"Our competitor has one." The weakest reason, and the most common. Their app may be unused. You can't see their download count, and you definitely can't see how many people opened it twice.
"Customers keep asking us things." A real problem. But the answer might be a better website, a WhatsApp flow, or an order-tracking page — none of which require anyone to install anything.
"We want to be on people's phones." Understandable, and backwards. You don't get onto someone's phone by building an app. You get there by being something they need often enough to keep.
"Our team needs it in the field." Frequently the strongest case, and the one most often overlooked in favour of a customer-facing app.
The three tests
An app earns its place when all three of these are true.
- They'll come back often. An app someone opens once is a website they had to download first. If your customer interacts with you twice a year, they won't keep your app — and every app they delete is a small permanent reminder that you asked for space you didn't earn. Weekly or daily use is where apps make sense. Occasional use is where websites do.
- It needs something only a phone provides. Location for tracking or finding the nearest branch. The camera for scanning, photographing or verifying. Offline working in places signal doesn't reach. Push notifications for things that genuinely can't wait. If your idea needs none of those, a website running in a phone browser can almost certainly do it.
- It removes a task someone does by hand every day. Not "improves the experience." Removes a specific, repeated, manual step — the booking taken by phone, the "where is the driver?" call, the job report written up at the end of the day. If you can't name the step it removes, you don't have an app yet. You have a wish.
Pass all three and an app is probably worth it. Fail any one and it's worth looking at the alternatives first.
The alternatives nobody mentions
- A mobile-first website. Most "app ideas" are websites that need to work properly on a phone. Faster to build, cheaper to maintain, no store approval, and nobody has to install anything to use it.
- A progressive web app. A website that can be added to the home screen, work partially offline and send some notifications. For a lot of business use cases, it covers most of what people wanted from an app at a fraction of the maintenance cost. The limitations are real — particularly around some notification and hardware features on certain devices — so it's a genuine option, not a universal one.
- A WhatsApp flow. In this region, a lot of customer interaction already happens there. A structured flow for bookings, confirmations and status updates meets people where they already are.
- An order-tracking page. If the problem is "customers keep calling to ask where their delivery is," a single tracking link sent by SMS solves it without a download.
If the honest answer is a website rather than an app, the next question is what that costs. We wrote that up for the UAE market and for India.
Where apps genuinely win
When the three tests pass, apps are among the highest-leverage things a business can build. The strongest cases we see:
- Field teams. Technicians, drivers, inspectors, sales staff visiting customers. They use it all day, it needs the camera and location, it has to work offline, and it replaces paperwork written up hours later from memory. This is often the best app a business will ever build, and it's the one nobody puts in their pitch deck because customers never see it.
- Frequent-transaction customers. Ordering, booking or reordering weekly. Saved details turn a five-minute task into a few taps.
- Live-status services. Deliveries, appointments, on-site jobs — anywhere the customer's most common question is "where is it?"
- Membership and access. Gyms, clubs, schools — where the app is how people get in, book or pay repeatedly.
That first case is worth its own argument, and we made it in what changes when your ERP works on a phone.
What it actually involves
The app is the part people picture. It's usually less than half the work.
The admin panel is where your team runs the operation — users, orders, bookings, jobs. Without it, the app is a screen with nothing behind it.
The backend handles the data, the logic and the connections to everything else you use.
Store submission involves listings, assets, review guidelines and review time you don't control.
Maintenance is the part most quotes leave out. Phone operating systems change regularly, and an app that isn't updated gradually stops working properly. Budget for the year, not the launch.
How we approach it
Before we quote an app, we test the premise. If a mobile-first website or a progressive web app does the same job, we'll tell you — that conversation costs nothing and has saved clients a great deal.
If an app is justified, you get a written scope: platforms, features, exclusions, the admin panel, what it costs and how long it takes. You approve it before development starts. We build the app, the backend and the panel your team runs it from, handle store submission, and include the update cycle afterwards.
We've also built and run our own software — StockFlow and RestPOS, with RestPOS running order management, kitchen display, billing and reporting in working restaurants. Living with our own products after launch is what taught us to take maintenance seriously.
The short version
Build an app if people will use it often, it needs something only a phone can do, and it removes a task someone does by hand every day.
If it fails any of those three, build a mobile-first website first. If that works and people keep coming back, you'll have real evidence the app is worth building — and a much clearer idea of what should be in it.