Web app, mobile app, or both? How to decide for your MVP

"We need an app" can mean three different things. Choosing wrongly at the start is one of the more expensive early mistakes, because it shapes your budget, your timeline and who can use the product on day one.

Ask these four questions

1. Where will your users be when they use it? If the product is used on the move, takes payments or depends on notifications, mobile is likely the main surface. If it's used at a desk, such as dashboards, back-office tools and long forms, the web usually fits better.

2. Do you need device features? Camera, biometrics, push notifications, contacts and offline use are strong reasons for a mobile app. A web app can do some of these, but not all, and not equally well on every phone.

3. How will people find and install it? A web app is a link. Anyone can open it from a message or a search result with nothing to download. An app has to be discovered in a store, installed and kept updated, which is a real hurdle on limited data.

4. What can you afford to build and maintain? Every surface adds cost: design, build, testing and updates. Doing two things well beats doing three things badly.

A common, sensible pattern

Many products work best as a shared backend with two clients on top: a mobile app for customers and a web admin dashboard for your team. One API and one database serve both, so you aren't building the product twice.

Our usual advice for a first version

• Build the smallest thing that proves people want it.
• Choose the surface where your users already are.
• Use cross-platform tooling so one mobile codebase covers iOS and Android.
• Put the logic in a proper backend from day one so you can add a second surface later.

Not sure which fits? Send us a short brief on the Start a Project page and we'll tell you honestly what we'd build first.