Web app vs mobile app: which should you build first?
Most projects that arrive asking for an app need a web app, and a meaningful minority genuinely need the phone. Getting this wrong is expensive in both directions — building an app nobody installs, or building a website for something that only works with a camera in someone's hand. We build both, so here is the question that actually decides it.
Build the web app first unless your product needs something only a phone can do — camera, location in the background, offline use, push notifications, or a place on the home screen people return to daily. A web app is one build, reaches anyone with a link, and updates the moment you deploy. The strongest argument for a mobile app is habit: if the product has to be opened repeatedly without being remembered, that icon is the product.
When each one is the right call
Build the web app
- People will find you through search, an email, or a link you send
- Usage is occasional or task-driven rather than daily
- It is used at a desk as much as on a phone
- You need to ship changes quickly and often
- You are still learning what the product should be
Build the mobile app
- You need the camera, background location, or device sensors
- It has to work with no connection and sync afterwards
- Push notifications are central to the product, not a nice-to-have
- People will use it daily and need it on the home screen
- Being in the store is itself a distribution or credibility requirement
The differences that actually matter
| Web app | Mobile app | |
|---|---|---|
| How people reach it | A link. Nothing to install, and it can rank in search | A store listing, and a deliberate decision to install |
| Shipping a change | Deploy — everyone has it immediately | Store review, then wait for people to update |
| Build effort | One build, every device | A separate build, plus store setup and release process |
| Offline | Limited, and awkward beyond simple caching | A solved problem — local storage and sync are normal |
| Push notifications | Possible, with real platform caveats | First class, and reliable |
| Camera and sensors | Basic access only, and inconsistent across devices | Full access, including sustained and background use |
| Presence | A tab or a bookmark, easily forgotten | An icon on the home screen |
| Search visibility | Yes — pages can rank and be linked to | Store search only; the content is invisible to the web |
| Payments | Your own processor, your own terms | Store rules apply to digital goods, including their commission |
| Ongoing overhead | Hosting and deployment | Two store accounts, release cycles, and OS updates each year |
Neither column is a verdict. Every row is a trade-off, and which side of it you want depends on the project — which is what the sections below work through.
The hard part of a mobile app is getting it installed
The build is the easy half. The difficult half is persuading someone to search a store, wait for a download, accept permissions, and create an account — before your product has demonstrated anything to them at all.
A web app skips all of that. Someone clicks a link and is inside the product. That difference is not a detail; it is often the difference between a product that gets evaluated and one that never gets opened. If your growth plan involves search, content, ads, partnerships or people forwarding a link to a colleague, every one of those channels lands better on the web.
The exception is real and worth stating plainly. Once someone has installed an app, you have something the web cannot easily give you: a permanent place on their home screen and permission to interrupt them. For a product that depends on habit — daily use, timely alerts, something opened without being remembered — that is worth the install friction and there is no web equivalent.
So the honest sequencing question is not which is better. It is whether you have earned the install yet. Most products have not, at the point they are deciding.
Three different things get called "an app"
A lot of confusion in this conversation is vocabulary, so it is worth separating the three.
A website presents information. Pages, content, a contact form — it is read rather than used, and its job is to be found and to explain. It should rank in search and load fast, and it does not need accounts or state.
A web app is software that runs in the browser. Logins, data, dashboards, workflows, things saved and returned to. It is distributed by URL, so it is one build for every device, and it updates when you deploy. Most business software people describe as "an app" is this.
A mobile app is installed from a store and runs on the device. It gets an icon, the camera, background execution, offline storage and reliable notifications, and in exchange it gets store review, a release cycle and the install barrier.
The productive version of the question is which of these three your product is, because a great many projects that begin as "we need an app" are a web app with a phone-friendly layout, and finding that out early saves a substantial amount of money.
What a responsive web app already does well on a phone
A web app built properly is not a desktop product that has been squeezed. It is designed for a phone screen and a thumb, and modern browsers cover more than most people assume.
It can be added to the home screen with its own icon and open without browser chrome, so it looks and launches like an app. It can cache enough to survive a brief loss of signal. It can take a photo, read a location once, and accept a card payment. On Android, notifications work well.
What it still does not do reliably is the demanding end of that list. Sustained background work, continuous location tracking, meaningful offline use with conflict resolution, tight integration with device features, and notifications you can depend on across all platforms are where the browser stops and the gap is not closing quickly.
Our practical test: write down the three things your product must do that a good mobile website could not. If the list is empty or vague, build the web app. If the list is specific and central to the value, you have your answer and it is worth the cost.
The sequence we recommend, and why
For most products the efficient path is a responsive web app first, a mobile app once there is evidence to justify it. That is not a way of selling a smaller project — it is the sequence that produces the better mobile app when you get there.
The web app answers the questions that would otherwise be answered inside an expensive app build: whether people want this, which features they actually use, what the data model needs to be, where the flow confuses people, and what the product is really for. Those answers cost far less to find on the web, where you can change something and have every user on the new version the same afternoon.
It also builds the backend you will need either way. A mobile app is a client on top of an API, and if that API already exists and is proven, the mobile build is genuinely a mobile build rather than a whole system with a phone attached.
By the time you have real users asking for notifications and a home-screen icon, you are not guessing at a feature list. You are building the app your users have already described, on infrastructure that works, for people who have already decided they want it. That is a much better app than the one that would have been built first.
Answered before you ask
Do I need a mobile app, or is a mobile-friendly website enough?
The deciding question is what your product must do that a browser cannot. If it needs the camera continuously, background location, genuine offline use with syncing, device sensors, or notifications that are reliable across both platforms, you need a mobile app. If it needs a login, data, a dashboard, forms and payments, a well-built responsive web app does all of that on a phone, reaches anyone with a link, and updates without waiting for a store review. There is a second, non-technical reason that is equally valid: habit. Products people should open daily benefit enormously from an icon on the home screen, and no amount of web polish substitutes for that. Absent one of those reasons, the web app is the better first move and usually the cheaper one.
Can I turn a web app into a mobile app later?
Yes, and the work is smaller than starting over provided the web app was built with a clean separation between the interface and the API. In that case the backend, database, business logic, authentication and payments carry across untouched, and the mobile build is a new client against a proven API — genuinely a fraction of building the whole thing again. The interface does not carry across: a phone app needs its own navigation, its own layouts and its own handling of platform conventions, and wrapping your website in a shell to avoid that is the approach most likely to be rejected by the stores and disliked by users. There is also a middle option worth knowing about, where an installable web app covers the home-screen icon and basic offline use without a store submission at all.
Will the app stores take a cut of my revenue?
It depends entirely on what you are selling and how. Both stores take a commission on digital goods and subscriptions purchased inside an app, and both require you to use their payment system for those, with reduced rates available for smaller developers under their small-business programmes. Physical goods and real-world services — anything delivered outside the app — are outside that, so an e-commerce or booking app can use its own payment processor without a commission. The rules around linking out to an external payment page have been in flux and vary by region, so this is worth checking against current policy for your specific model rather than relying on a general answer. If your revenue is digital subscriptions, factor the commission in before deciding a mobile app is the cheaper channel; for many subscription products, the web remains the better place to take the payment even when the app is the better place to use the product.
How long does each take to build?
Ranges are only useful with the scope attached, so treat these as shape rather than quotes. A focused web app with authentication, a core workflow and payments is typically a matter of weeks, and our MVP track deliberately targets three to four for something deployed and revenue-capable. A mobile app of comparable scope takes longer, and the additional time is not mostly coding: it is store accounts, signing and provisioning, testing across a spread of real devices, review submission and the first release cycle, plus the fact that a mistake takes days to correct rather than minutes. Where the backend already exists, a mobile client on top of it is much faster than a first build. We quote against a defined scope after the call, and we design a free prototype first so the scope is something you have seen rather than something you have read.