When is an app worth building? A test to run first
“We need an app” is how many first conversations start. Sometimes it is true. Often an app turns out to be an expensive way to learn that customers did not want to download anything.
This is the bar we think an app idea should clear before anyone writes code, including our own.
The bar an app has to clear
An app asks a lot of a user: a download, storage space, a home-screen slot and trust. In return it has to offer something a website cannot, or the website wins by being one tap away with nothing to install.
So the useful question is not “would an app be nice?” but “what does this idea need that only a phone can give?”
Good reasons to build an app
Habit: people will return daily or weekly. Phone features: camera, sensors, offline work, or notifications people want. Speed of access: open, do the thing, done.
Our own apps show the pattern. Ultim8, a friends-and-family fitness competition, is an app because the data it needs, steps and exercise, lives in the phone and its health services. Tabful, a bill-splitting app, hands payments to your UPI app, scans QR invites and can lock behind your fingerprint. These are phone jobs.
Bad reasons to build an app
Prestige, copying a competitor, or wanting a place on customers' phones for marketing. If honest usage is once a month, people will delete it, and stores, reviews and updates will cost you attention that a website never asks for.
In India, many flows founders imagine as apps, such as enquiries, bookings and order updates, are better served by a fast website plus WhatsApp, where customers already spend their day.
Web first, app second
Mudra, our email signature and document-signing product, is a web app, because that work happens at desks in browsers. Tilo Grid shows both halves: its tools run in the browser with nothing to install, and an Android app exists for what a phone adds, such as a saved projects library and video frames.
If usage shows people need something on their phones every day, a mobile app becomes an informed investment instead of a guess.
Choosing how to build it
If you need both iPhone and Android, one shared codebase is usually cheaper to build and maintain than two native apps. We have used Flutter, native Kotlin and React Native on different projects, and the right choice depends on the features and the team that will maintain it.
Start with the platform your customers use. In India that is usually Android, though the answer depends on your audience, so check your own analytics before deciding.
Frequently asked questions
Should I build for iOS or Android first?
Start with where your customers are. In India Android has the larger share, but check your own audience. If you need both, a shared codebase usually costs less than two separate apps.
How long does a mobile app take to build?
It varies widely with scope. A single-purpose app is far quicker than one with accounts, payments and a backend. Ask for a phased plan with a first release that does one thing well.
Do I need an app if my customers are on WhatsApp?
Often not. Enquiries, bookings, reminders and support all work well as a fast website plus WhatsApp. Build an app when the product itself is the tool, not just the channel.
Have something worth building?
Tell us what you're trying to make happen. We'll reply with a plan, not a brochure.
Start a project