BUILDING PRODUCTS

Web app, mobile app or both? How to choose for your first product

A clear comparison of web apps, native mobile apps, cross-platform apps and progressive web apps, with the questions that decide which one your product should start with.

"Should we build an app or a website?" is one of the first questions founders ask, and one of the most expensive to get wrong. The answer is rarely about technology. It depends on who your users are, where they are when they need you, and what the product needs to do on their device.

This guide explains the options and gives a set of questions to settle the choice.

The four options

Web app

A web app runs in the browser on any device. There is nothing to install: users open a link.

Strengths: one codebase for desktop and mobile, instant updates, easy to share, discoverable through search, and well suited to dense information such as tables, dashboards and forms.

Limitations: limited access to some phone features, no home-screen presence unless the user adds it, and notifications on phones are more restricted than in native apps.

Native mobile app

A native app is built separately for Android and iOS using each platform's own tools, and installed from the Play Store or App Store.

Strengths: the best performance and the fullest access to the device: camera, offline storage, background tasks, notifications and payment flows.

Limitations: two codebases, which roughly doubles the work; store review for every release; and users must be persuaded to install it.

Cross-platform mobile app

Frameworks such as Flutter and React Native let one codebase produce apps for both Android and iOS.

Strengths: most of the benefits of native, at much closer to the cost of building one app. For the majority of business apps, the performance difference is not noticeable.

Limitations: occasional platform-specific work for unusual features, and dependence on the framework keeping up with new operating system releases.

Progressive web app (PWA)

A PWA is a web app that can be added to the home screen, work offline to a degree, and in many cases send notifications.

Strengths: a single web codebase with some app-like behaviour; a good bridge when you are not sure an app is justified.

Limitations: support varies, especially on iPhones, and many users do not know how to install one.

The questions that decide it

Where is your user when they need you?

If they are at a desk, as accountants, analysts and office teams are, start with the web. If they are on their feet, as shop owners, field sales staff and delivery workers are, start with mobile.

How often will they use it?

Daily use justifies an installed app, because a home-screen icon and notifications bring people back. Occasional use, such as booking, applying or checking a status, is usually better served by a link that works without installing anything.

What does it need from the device?

Scanning barcodes, photographing documents, working offline in a shop with poor connectivity, or taking UPI payments all favour a mobile app. Large tables, bulk editing and printing favour the web.

How do users find you?

If people will discover you through Google, the web matters, because app store listings are not a substitute for search. If they come through a referral from someone they already work with, an app install is less of a barrier.

What can you maintain?

Every platform you support is a product you have to keep updating. A small team is usually better off doing one platform well than two badly.

When you need both

Some products serve two different people, and each of them works differently. A practice tool for accountants, for example, has firms at desks and business clients on phones. In that case the right answer is often:

  • a web app for the professional user, built for depth and speed; and
  • a mobile app for the client, built for simplicity and a few frequent actions.

That is how we designed SquareBooks: a web workspace for CA firms and a phone app for the business owners they serve, sharing one set of records underneath.

If you need both, still decide which one to build first. Start with the side whose behaviour your product depends on, and serve the other side with something simpler, such as email, a web link or a shared report, until the first is working.

Some rules of thumb

  • Consumer product used daily on the go: cross-platform mobile app first.
  • B2B tool used at a desk: web app first.
  • Marketplace or two-sided product: the side you need to change most, first.
  • Content or discovery product: web first, for search.
  • Unsure: a responsive web app or PWA, then build the app once usage justifies it.

Key takeaways

  • Choose the platform from the user, not the technology.
  • Web suits desk work, depth and discovery; mobile suits frequent use on the move and device features.
  • Cross-platform frameworks make a mobile app affordable for most businesses.
  • If you need both, still choose which comes first.

Not sure which fits your idea? Tell us about it. We build web, mobile and cross-platform products and are happy to talk through the trade-offs.