What a web app costs to build
Browser applications are priced differently from native mobile apps, mostly because they are released differently and tested differently.
- $15K – $90K
- What most web applications cost
- −10%
- Off application development, and nothing off anything else
- $55 / hr
- Blended across design, engineering, QA, and management
A web application is a different product from a mobile app, with a different distribution model, and for a large share of business software it is the correct one. The build cost is somewhat lower. The difference in how you operate the thing afterward is much larger, and that is the part worth deciding on.
This page is about that trade: what the browser saves you, what it costs you, and the fairly common case where the honest advice is that you do not need a mobile app at all.
What web applications cost
The same three shapes, with the platform discount applied. The discount is smaller than the folklore suggests, and the real saving sits somewhere else entirely.
$15,000 – $25,000
Focused first version
About 9–15 weeks
One core workflow, one kind of user, a new backend, and a responsive layout that works on a laptop and does not fall over on a phone. Deployed the day it is ready.
$30,000 – $55,000
Production build
About 3–5 months
Several workflows, multiple user types with different permissions, reporting, and the administrative side built in rather than bolted on. That last part is where a web application has a structural advantage.
$55,000 – $90,000
Complex build
About 4–6 months
Real-time collaboration, heavy reporting over large datasets, migration of years of existing data, single sign-on, or an enterprise security review. Compliance and scale are what put a web project here.
These are the three shapes of project that show up most often. Treat the boundaries as soft: work lands between the bands constantly, and a project can sit at the top on one dimension and the bottom on every other. The calculator prices the description you give it instead of sorting you into a box.
Why web is a little cheaper, and only a little
In the model behind this calculator, targeting the browser instead of native mobile takes about 10% off the application development line and nothing off anything else. Design costs the same. The backend costs exactly the same. Integrations, reporting, migration, and project management do not move at all.
- −10%
- Application development
- 0%
- Design, backend, integrations, reporting, migration, management
That is the whole platform discount. If someone has quoted you a web application at half the price of the mobile one, they changed the scope rather than the platform. The browser’s real advantage arrives at release.
No store review: you ship on a Tuesday afternoon
There is no queue, no reviewer, no rejection over a screenshot, and no waiting for a fix to reach users who have not opened an app store in a month. You deploy, and everyone is on the new version at their next page load. That is the entire release process, and its consequences reach further into the project than the 10% does.
Every mobile timeline on this site carries two to three weeks that no amount of staffing compresses: kickoff, your own review cycles, and store review. A web project keeps the first two and loses the third. It also lowers the cost of being wrong. A bug found on Thursday morning can be gone by Thursday afternoon, which changes how much analysis a decision needs before it is safe to make. Over the life of a product that is worth far more than the discount on the initial build.
The flip side is that everyone is always on the latest version, including the version with the mistake in it. Web projects need staging environments and a rollback plan the way mobile projects need a device lab. The risk just moved somewhere else.
A browser matrix instead of a device matrix
Three rendering engines are in real use: Chromium, WebKit, and Gecko. A meaningful test plan covers those three across a few viewport widths, plus whatever your users bring. Compared with an Android device lab that is cheap, and it still costs something. Safari is where cross-browser defects concentrate, and "it works on my laptop" has ended more than one launch.
- 3
- Rendering engines a web test plan has to cover
- 4
- Breakpoints, against eleven handsets from four manufacturers
The device dimension survives, because most web applications now get used on phones at least some of the time. But "responsive and correct at four breakpoints" is a much smaller commitment than "correct on eleven physical handsets from four manufacturers running five OS versions," and the QA line reflects that.
What you give up
Four capabilities are worse in a browser or missing outright. If any one of them is central to your product, the decision is already made.
- Reliable push notifications
- Web push works on desktop browsers and on Android. On iOS it works only after the user has explicitly added your site to their home screen, which most people will never do. If a notification is how your product creates value, say a dispatch alert or a time-sensitive approval, build it somewhere other than the browser.
- Real offline operation
- A service worker can cache the application shell and some data, which is often enough for a read-mostly tool. Capturing a full shift of work with no signal at all and reconciling it later without losing a record is a different problem, and it remains native territory. It is the most common reason a business needs a mobile app rather than a responsive site.
- Hardware
- Camera and location are available and workable. Bluetooth is missing from the browser most people use. Background execution, large reliable local datasets, and integration with a manufacturer’s device SDK are off the table entirely, with no partial version to fall back on.
- Presence
- There is no store listing, so there is no store search and no icon that arrives on the home screen by default. For a consumer product competing for attention that matters. For an internal tool that people reach from a bookmark or a link in an email, it is a non-issue.
You may not need an app
A good number of projects described as "an app" are a web application with a login. Built that way they cost less and ship sooner.
The test is where the work happens. If your users are sitting at a desk, on a laptop, in a browser they already have open, with a keyboard and a large screen, a native mobile app is an expensive way to reach them and a worse experience once you have. Anything that involves reading a table, comparing records, typing more than a sentence, or having two things open at once is desk work, and desk work belongs in a browser.
If your users are standing up, moving between locations, holding a device in one hand, scanning something, taking photographs, or working where there is no signal, you need mobile, and no amount of responsive design substitutes for it.
- $9K – $15K
- The office-facing companion, priced as the second product it is
There is a middle case that catches people out. Plenty of businesses need both and describe only the mobile half. Almost every mobile application of any substance has an office-facing companion for managing users, data, and the content the app displays. That companion is a web application, priced as a second product, and it is typically the largest single line item after the app itself. Budget for one thing when you are going to need two and you are short before anyone writes a line of code.
Common questions about web app cost
How much does it cost to build a web app?
A focused first version is usually $15,000–$25,000. A production web application with several workflows, multiple user types, and reporting is usually $30,000–$55,000. Real-time collaboration, large-scale data migration, single sign-on, or an enterprise security review push a project into the $55,000–$90,000 range and sometimes past it.
Is a web app cheaper than a mobile app?
Modestly. Targeting the browser takes roughly 10% off the application development work and nothing off design, backend, integrations, or project management. The bigger saving is operational rather than upfront: no store review, no waiting for users to update, and a fix that ships the same day it is written.
Can a web app be installed like a native app?
Partly. A progressive web app can be added to the home screen, run in its own window without browser chrome, and cache enough to survive a poor connection. On Android that experience is close to a native install. On iOS the user has to add it manually and most will not, and web push only works once they have. Treat installability as a bonus rather than a strategy.
Do I need a web app and a mobile app?
More often than people expect. If field or customer-facing users need a phone, and someone in an office needs to manage users, review submissions, or configure what the app shows, that is two products. The admin side is routinely described in one sentence and priced at zero, and it is usually the largest line item after the app itself.
How long does a web app take to build?
A focused first version is usually 9–15 weeks, a production build 3–5 months. Web timelines lose the store review window that mobile projects carry, but they keep the fixed weeks for kickoff and your own review cycles. That is calendar time nobody can staff their way out of.