Most businesses that ask for an app need a faster mobile website. Here is the test that separates the two, before you spend the difference.
Key Takeaways
- Most businesses that ask for an app need a faster mobile website.
- Here is the test that separates the two, before you spend the difference.
If you cannot name something your app would do that a website cannot, you need a better website. That is the whole test, and it saves most businesses the difference between a site and an app.
The request usually arrives as "our competitors have an app". That is a real business concern, but it is not a requirement, and building the wrong thing to answer it is expensive twice: once to build, and again every year to maintain.
The four questions
Answer these honestly and the decision usually makes itself.
Does it need to work without a connection? Genuinely, not theoretically. A delivery rider in a valley needs offline. A customer browsing your catalogue at home does not.
Does it need hardware a browser cannot reach? Background location tracking, Bluetooth peripherals, reliable background sync. Camera and basic location work fine on the web.
Do people use it more than once a week? An icon on a home screen earns its place through repeat use. For something people touch twice a year, the install is a barrier, not a convenience.
Are notifications central, or nice to have? If your product is built on getting someone's attention at the right moment, native push is meaningfully better. If notifications are a growth idea rather than the point, they do not justify an app.
One clear yes usually means an app. Four soft maybes mean a website.
What the website route buys you
No install barrier, no app store review, and one thing to maintain instead of three. You ship a fix in the afternoon rather than waiting for review. Your customer taps a link and is using it, which for a first-time visitor is the difference between a sale and a shrug.
A well-built mobile site with a home screen install, offline caching for what makes sense, and web push covers a lot of what people imagine an app is for. It is not marketing to call that a PWA; it is a real set of browser capabilities.
What the app route actually costs
The build is the visible part. The ongoing part is the one that surprises people: OS updates that break things, store policy changes that require a new submission, crash monitoring, and a release process for every fix.
An app that is not maintained does not stay still. It eventually fails a store requirement and stops being installable, which is a worse outcome than never shipping one.
Our own numbers: a business website starts from NPR 40,000 and a cross-platform app from NPR 150,000, before the ongoing support each needs. The gap is not the interesting part. The recurring commitment is.
A reasonable middle path
Build the mobile site first and instrument it. If a meaningful share of your traffic returns weekly, if people are installing it to their home screen, if you can point at a workflow that keeps failing because of connectivity, you now have evidence for an app and a clear specification for what it should do.
That order costs less and produces a better app, because you are building for behaviour you have observed rather than behaviour you assumed.
Enjoyed this article? Share it with others!
Written by
Antbytelabs
Writing about the software we build at Antbytelabs in Bhaktapur, Nepal.