Three ways a phone already does the work
Most business-on-a-phone in India is already one of three things. A public site the customer can open without installing anything. A WhatsApp thread where the real yes or no lives. A web page behind a login that staff bookmark. None of those is a store listing. All three can be the right next spend. Confusing them with “we need an app” is how you fund a wrapper and still run the morning in a group chat.
A responsive site is the default when the user is a stranger, or a customer who will visit twice a year. They will not fetch your icon. They will search, they will tap a link, they will call. If that page is slow, or jumps, or hides the phone number, you have a web problem. You do not have an app-shaped hole.
WhatsApp is the default when the user is a regular — a dealer, a driver, a supervisor — and the job is a short message plus a photo. Replacing that with an app they must install, update, and remember a password for is a product meeting, not a moral upgrade. Sometimes you should still replace it, because groups do not audit and numbers get lost. Sometimes you should put an official list behind the photo and leave the chat as the pipe. That decision is operational. It is not “mobile strategy”.
A web application on a phone browser is the default when staff will do the same job they do at a desk, and a decent connection exists. Today’s list, a confirm, an undo — those can be a web application, not a store binary. If you need the longer distinction, that page is the one. Here the question is narrower: do you need a listing at all?
Who actually needs a store listing
You need a store listing when the same people will open the same job most days, and a browser tab will fail them. Offline at a site with no signal. Camera or scanning that the browser keeps fighting. A hardware pairing. A push that must arrive when the page is closed, and you have measured that SMS or WhatsApp will not do. Those are reasons. “Our competitor has an icon” is not a reason. “The intern said everyone has an app” is not a reason.
You also need a listing when your customers already look for you that way — a consumer habit, a repeat order, a ticket they will show at a door. A manufacturer’s dealer network in Kerala often does not look that way. They look in the group, or they call. An icon they installed once in a training and never opened again is not a channel. It is a souvenir.
Staff-facing apps can be justified when the phone is the workplace: delivery, field service, a count on the floor. Even then, start with a mobile web path if the job is simple. The store becomes interesting when you are ready to sign the developer accounts, the signing keys, the review waits, and the “please update” conversations. Those costs are real even when nobody quotes a fantasy total in a slide.
If the daily user is a stranger comparing three vendors, you want a site Google can read. Stores do not rank your service page. Browsers do. Spend the money where the stranger already is.
Responsive site versus app versus WhatsApp
| Path | User already there? | Install tax | When it wins |
|---|---|---|---|
| Responsive public site | Search, ads, shared links | None | Strangers, rare visits, SEO |
| Logged-in mobile web | Bookmark or home-screen shortcut | Low | Staff jobs on a connection |
| Already in the pocket | None | Short yes/no, photos, reminders | |
| Store app | Only after install and login | High, two stores | Daily job, device features, offline |
Read the table with a real person in mind. The receptionist. The dealer. The driver. The owner who wants a badge on the homepage. The last one is the most expensive user to design for, because they do not open the thing on a Tuesday.
A home-screen shortcut to a well-built web app is an option people forget. It is not as pretty in a pitch. It also skips review queues. If the job is today’s list and a confirm, try that before you hire store screenshots.
What the app pitch usually skips
Two stores, two review cultures, two “your build is missing a privacy link” delays. A release when iOS and Android disagree about a permission. A device you do not own, with an OS you did not test, in a language you did not screenshot. None of that is a reason never to build. All of it is a reason not to make the app the first spend when the site still cannot show a price or take an enquiry on a phone.
There is also the uninstalled majority. You can spend months on an icon and discover that dealers will not use storage for you, or that staff already have a full home screen of bank and government apps. Forcing an install in a workshop produces a graph for a week. Then the group is busy again. Measure opens after the workshop glow fades. If you cannot measure, you are not ready to pay for a listing.
Push notifications sound like a feature and behave like spam unless the message is the job. “Your cart is waiting” is not a job for a B2B parts line. “Load 14 is at the gate” might be. If WhatsApp already delivers that sentence to the right person, an app push is a second channel to keep in sync. Two channels that disagree are worse than one unofficial channel everyone believes.
Offline is the honest hard case. If the field truly has no data, a browser tab will disappoint. Then you are in app territory, with sync that will break and a conflict you must design. Budget that as software, not as a skin. If the field has patchy data and the job can wait ten minutes, a mobile web page that saves a draft may be enough. Check the field. Do not check a brochure from a coastal coworking space.
Wrong next spend, in sentences you can reuse
Wrong: the public site is a desktop souvenir, and the proposal is a customer app. Right: make the site work on a mid-range Android, with a visible number and a form that submits. That is web development. It is also cheaper to abandon if you guessed the offer wrong.
Wrong: staff will not use the desktop tool, so you wrap it in a WebView and call it mobile. Right: fix login, one job, undo, and today’s list. If they will not open a browser, they will not open a wrapper. The wrapper only adds a store account.
Wrong: WhatsApp is messy, so an app will make the company look modern. Right: decide which messages must become records. Put those in a system. Leave the rest in chat until you know they matter. Modern is a record you can find in August. It is not an icon.
Wrong: “phase two is the app” written before phase one has a user. Right: phase one has a Tuesday user and a count. The app is a later sentence if the count says the phone must do more than a browser allows. Mobile app development is a real service when that sentence is true. It is a drain when it is a sequel in a pitch deck.
A short test before anyone opens Xcode
- Name the person who will open this on a Tuesday without you.
- Name the one job they must finish.
- Say whether they already do that job in a browser, a group, a call, or a notebook.
- Say which of those paths fails for a reason a store binary would fix — not a reason a better web page would fix.
- Say who will publish updates when a store rejects a build in the week you are at a wedding.
If you cannot answer those, you are not choosing an app. You are choosing a feeling. Feelings are allowed in brand work. They are a poor way to pick a runtime.
If you can answer them and the binary is still the only fit, good. Write the offline rules. Write the login on a shared phone. Write what happens when two people edit the same stop. That document is the project. Screenshots of other companies’ apps are not.
Customers, staff, and the shared-phone problem
Customer apps assume a personal phone and a willingness to keep you. Staff apps often meet a shared counter phone, a driver’s personal phone that also holds the family, or a supervisor who will not give you the number for OTP. Design for that or do not bother. A beautiful onboarding that needs a private email is a city product wearing a village deployment.
Kerala SME reality: the person at the gate may not have a Play Store account they remember. The dealer may have three groups and no patience for a PIN. The owner may want the icon on their own phone as proof the company is digital, then never open it. Build for the gate and the dealer, or admit you are building a prop. Props have a price. They do not have users.
Language matters. If the job is done in Malayalam in the group, an English-only app is a training tax every week. Mobile web can ship a language change without a store wait. That alone has killed more “quick app” ideas than any lecture about cost. Put language on the list next to offline.
Permissions matter. Camera, location, files — each one is a reason to abandon install. Ask only for the permission the job needs, on the screen that needs it. A first-launch barrage is how you get “don’t allow” and a silent failure that looks like a bug in your office and a shrug on the road.
What to spend on instead, this quarter
Make the money URLs work on a phone. Service pages, contact, the article that already has impressions. If you need the publishing-versus-software split, read website versus web application and price them as two jobs even when they share a header.
If staff are the users, spend on the Monday tool: login, one job, undo, today’s list. That may be mobile web. It may later become an app. It should not start as a listing with an empty job.
If WhatsApp is the system of record, spend on pulling the few facts that must survive — the order, the dispatch, the complaint — into a place accounts can find. Leave the chatter. You do not need a chat clone. You need a record. The clone is how you lose both the group and the books.
When the store is finally the right spend, treat mobile app development as a product with a release train, not as a brochure PDF. We will ask for the Tuesday user and the failed browser reason before we talk icons. If those are missing, the next spend is the site or the internal tool. That is not us being difficult. That is how you avoid an icon that looks like progress in May and looks like a folder in September.
A last honest pattern: the owner saw a consumer app they like and wants the same badge on the company site. Consumer apps have millions of people who already wanted the job. You have a few dozen people who already have a group. Copying the badge copies the screenshot, not the habit. Habit is the asset. Spend to serve the habit you have, or to build one you can count. Do not spend to look like a store. Stores are full of icons nobody opened this week. Yours does not need to join them to look serious. A site that answers, a tool staff open, a chat that is no longer the only archive — those look serious on a Tuesday. That is the spend we will defend. The other one we will talk you out of, once, and then we will build what you still insist on, with the costs written down so the insistence is informed.