"Let's build an app" is usually the wrong instinct

We build mobile apps. So it’s a slightly odd thing to admit that the phrase “we should build an app” is, more often than not, a wrong turn.

It usually arrives fully formed. A business owner has a problem, or a competitor has an app, or a customer said something offhand, and the conclusion lands before the problem’s even been described: we need an app. From there the conversation is all features and app stores and what colour the icon should be. The question that got skipped, the one that decides whether any of this is a good idea, is what the app is actually for.

An app is a delivery mechanism, not a strategy. Asking for one is like walking into a builder’s office and opening with “I’d like a spiral staircase.” Maybe you do. But the builder’s first job is to ask what you’re trying to get to, because there might be a door.

What people usually mean when they say “app”

Most of the time, “we need an app” is a stand-in for something more specific that hasn’t been said out loud yet. Dig a little and it turns into one of these.

• “Our process is a mess and I want it in one place.” This is the most common one, and an app is rarely the fix. The problem is the process, not the platform. A custom business system that runs in a browser usually solves this better and cheaper than anything in an app store.
• “I want to be on customers’ phones.” Fair goal. But a website that works properly on a phone gets you onto the phone without asking anyone to download, install, sign up and remember you exist. The bar for a customer installing your app is high, and most businesses can’t clear it.
• “A competitor has one.” The competitor might be right, or they might have spent six figures on a thing their customers opened twice. Their app is not evidence. It’s just a fact.
• “I’ve got an idea for a product.” Now we’re talking, because this is a real reason to build. But even here, the first version usually isn’t a native app. It’s the smallest thing that proves people want it.

None of these are silly instincts. They’re just the symptom, not the diagnosis. The job is to name the actual problem before deciding on the shape of the solution.

The web app you’re underrating

Here’s the part the app-store excitement skips over. For a huge share of what businesses want, a web app is the better tool, and it’s not close.

A web app runs in the browser on any device. No download, no app store approval, no separate iOS and Android builds, no waiting on Apple to bless an update. You fix a bug at 10am and every user has the fix at 10:01. Your staff open it on the ute, the customer opens it on their laptop, the office opens it on the big screen, and it’s the same thing, updated in one place. For internal tools, booking systems, dashboards, portals and most customer-facing workflows, that’s not a compromise. It’s the right answer.

Native apps earn their spot for real reasons, and when those reasons are present you build the app without hesitation. You need it when the thing genuinely has to work offline in the paddock or on site with no signal, when it leans on the phone’s hardware in a serious way, when push notifications are core to how it works rather than a nice-to-have, or when it’s a consumer product where being in the app store and on the home screen is part of the point. Those are good reasons. “It feels more legit” is not one of them, and getting an app launched is harder than most people expect before you’ve even proven anyone wants it.

If you can’t point to one of the real reasons, the honest answer is usually a web app that happens to work brilliantly on a phone.

The cost nobody mentions until later

The build is the cheap part. People find this hard to believe until they’ve lived it.

A native app isn’t one thing you build once. It’s two codebases if you go fully native, or one that still has to be tested against both platforms. It has to keep up with operating system updates every year or it starts breaking. It needs an Apple developer account and a Google one, each with their own rules, review queues and the occasional rejection that holds up your release. When Apple changes a policy, you comply or you’re pulled. And every user is running whichever version they last bothered to update to, so you’re supporting several versions of your own app at once.

None of that is a reason never to build an app. It’s a reason to be sure the app is worth carrying, because you’re not buying a thing, you’re adopting one. The real cost of a custom app is the years after launch, not the months before it. A business that builds an app to solve a problem a web app would’ve solved has signed up for a decade of maintenance it didn’t need.

How to actually decide

Skip the features conversation. Start with these, in this order, and the right shape usually falls out on its own.

What’s the problem, in one sentence, with no technology in it? “Our quotes take three days and half of them never get sent.” “Field staff are filling in paper forms that get lost.” “Customers can’t book without ringing us.” If you can’t say the problem without saying “app,” you haven’t found the problem yet.

Who’s the user, and will they really install something? Your own staff, told to use it, will install an app. The general public, mostly, will not, unless you’re something they’ll open weekly. Be honest about which one you’ve got, because the answer rules half the options in or out.

Does it need the phone itself, or just to be reachable on a phone? Offline in a dead-signal paddock, camera, GPS, barcode scanning as a core function: that’s a real app. “People will use it on their phones sometimes” is a web app.

What’s the smallest version that proves this is worth it? Before anyone builds the full thing, what’s the smallest slice that tells you whether the idea works and whether people want it? Build that first. It’s cheaper to learn you were wrong on a prototype than on a finished product.

Answer those four honestly and you’ll almost always know whether you need an app, a web app, a fix to a broken process, or a small prototype to test an idea before you spend properly on it.

We’ll tell you when you don’t need us to build the big thing

Because we build apps, we’ve got no incentive to talk you out of one. Which is exactly why it’s worth saying that we regularly do. A business comes to us wanting a native app, we ask the four questions, and often what they actually need is a web app for a third of the cost and none of the app-store grief, or a process fixed rather than a screen added.

That’s not us being difficult. It’s the difference between selling you what you asked for and building you the thing that solves the problem. Sometimes that thing is genuinely a native app, and when it is, we’ll build it properly and tell you honestly what carrying it will cost. But we’ll work out the problem first.

If you’ve got “we need an app” in your head and you’re not sure whether that’s the answer or just the first idea, tell us the problem instead, in a sentence with no technology in it. We’ll help you find the right shape before anyone spends a dollar building the wrong one.