Every month a founder asks me to build them an app. Nine times out of ten, what they actually need is a URL.
“We need an app” has become shorthand in Malaysian SME conversations for “we need custom software.” The word has quietly eaten every other framing. But the decision to build a native mobile app — iOS and Android — instead of a web-based tool has real, expensive consequences, and most of them don’t get weighed before the project starts.
Here’s what you’re paying for when you default to native.
Install friction
Getting someone to download and install an app is one of the hardest asks in software. App store listing, permissions prompts, storage space, the gap between “I heard about this” and “I’m actually using it” — every step loses people. Your own staff will install what you tell them to. Your customers, probably not. Every extra tap between “hears about it” and “uses it” is a person you’re losing. A URL, by contrast, is zero-install: send it in a WhatsApp message and the person is one tap away.
Two codebases, not one
An iOS app and an Android app aren’t one piece of software, they’re two. You pay to build both. You pay to maintain both. You pay every time Apple or Google changes something and you have to republish both. You pay for the extra QA surface area. You pay for the extra deployment process. And if you’re trying to keep feature parity between the two, you pay for that, too.
A web tool is one codebase that runs on every device that has a browser. Which, these days, is every device.
Update lag
Ship a bug in a web tool, fix it, deploy — your users are on the fixed version in seconds. Ship a bug in a native app, and the users who haven’t turned on auto-updates are on the broken version until they happen to open the App Store. For a small business running a real operational workflow, that lag matters. It’s the difference between “the bug is fixed” and “the bug is fixed in the version most of our users aren’t on yet.”
The push notifications objection
The one I hear most: “but we need push notifications.” You almost certainly don’t. What you actually need is a way to reach your users when something happens. SMS, WhatsApp and email already live on devices your users already trust, and you don’t have to ship an app to use them. In many cases they reach people faster and more reliably than app notifications do.
When native actually makes sense
A short list:
- Heavy device hardware use — camera-first workflows, GPS tracking, Bluetooth devices, offline-critical flows
- High-frequency trusted use — an internal staff app used daily, where the install happens once and the friction vanishes
- A genuine home-screen play — a B2C product trying to live next to Instagram and Grab. Different rules apply.
That’s the list. Most SME software problems aren’t on it. A client portal, an internal dashboard, a booking form, a quotation system, an inventory tracker — none of these need to be an app. All of them should be a URL anyone on your team can open on any device without installing anything.
The web has quietly gotten very good
Modern browsers handle cameras, file uploads, geolocation, offline caching, add-to-home-screen icons that open like an app, and every payment rail that works in Malaysia. For the kind of software most small businesses actually need, the gap between “a website” and “an app” is smaller than founders think, and still shrinking.
The default should be web. Build native only when you can point to a specific capability you genuinely can’t do without. Defaulting to native because “we need an app” got stuck in your head means paying roughly twice as much to build the wrong thing.
So the next time someone tells you you need an app, ask them: does this have to live on the home screen, or can we just send people a URL?
The answer, almost always, is “a URL.”