Web app, mobile app or both? Choosing your first build

“We need an app” is one of the most common ways a software conversation starts. Sometimes a mobile app is exactly right. Often a web application would serve users better, cost less and launch sooner. And sometimes the answer is both. The way to decide is to start with the people who will use it.

Start with frequency and context

Two questions do most of the work:

• How often will people use it? Daily or weekly use favours a mobile app. Occasional use favours the web.
• Where are they when they use it? At a desk, on the move, in the field with a poor signal, or on a shared office computer?

An app installed on someone’s phone has to earn its place. If people only need it a few times a year, most will not install it, or will delete it to free up space.

When a web application is the better choice

• Occasional or one-off use: applying, booking, checking a status, paying an invoice.
• People arrive from search engines, links or emails and should not have to install anything first.
• Many kinds of user, including desk-based staff, who work better on a large screen.
• You want to update it often, without waiting for app store review or for users to install updates.
• One codebase for every device, which keeps cost and maintenance down.

Modern web applications can also be installed on a phone’s home screen and cache some content for offline use. For many projects that is enough.

When a mobile app is the better choice

• Frequent use: daily tasks, regular orders, ongoing services.
• Notifications matter: reminders, alerts and updates that bring people back.
• Offline work: field staff recording inspections, deliveries or surveys with a weak or no connection.
• Device features: camera, location, biometrics or background tasks used heavily.
• Presence: an icon on the home screen is a constant reminder of your service.

Nigerian factors that change the answer

• Android is the majority. Most smartphones in Nigeria run Android, so many projects start there, or build Android and iOS together from one codebase. Check your own users, though: some audiences skew towards iPhone.
• Storage and data cost money. A large app, or one that downloads a lot, will be uninstalled. Keep installs small and data use modest.
• Connectivity varies. Design key screens and forms to work offline and sync later, whichever platform you choose.
• Not everyone has a smartphone. For some audiences, USSD or SMS channels will reach more people than any app or website.

Often, the answer is both

Many successful products use one shared back end, with a web application for staff and administrators and a mobile app for customers or field teams. The business logic and data live in one place, exposed through an API, so each front end stays simple. You can launch one first and add the other when it is justified.

Cost and maintenance

Mobile apps carry ongoing work that is easy to underestimate: two app stores with their own rules and reviews, new phone operating system versions every year, and updates users must install. Web applications avoid most of this. Neither is free to maintain, so budget for support from the start.

A quick way to decide

• Used rarely, by many people, often from search or links: start with the web.
• Used daily or weekly, needs notifications or offline work: build a mobile app.
• Staff need management screens and customers need a phone experience: plan both on one back end, and launch the most valuable one first.

Start small

Whatever you choose, the fastest route to a good product is a focused first version that does one job well, tested with real users early. It is far easier to add features to something people already use than to rescue a large launch nobody needed.