What a web app costs to build

Browser applications are priced differently from native mobile apps, mostly because they’re released differently and tested differently.

$15K – $90K: What most web applications cost
−10%: Off application development, and nothing off anything else
30%: Of the backend work survives if you already have a documented API

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’s 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 don’t need a mobile app at all.

What web applications cost

The same three kinds of project, 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 doesn’t fall over on a phone. Deployed the day it is ready.
$30,000 – $55,000
Production build
About 3–5 months
A few jobs to do, users who shouldn’t see the same things, the reports somebody asks for every month, and the admin side built in instead of bolted on. That last part is where the browser wins outright.
$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 kinds of project that show up most often. The lines between them are soft. Plenty of work lands in the gaps, and a project can be complicated in one way and straightforward in every other. The calculator prices what you describe 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 don’t 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, not 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 haven’t opened an app store in a month. You deploy, and everyone is on the new version at their next page load. That’s 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

Device testing does not go away, 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’s 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’s 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’s 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, and at a smaller budget the gap is wide enough to change what you can have: what $25,000 buys prices both.

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’s 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’s typically the largest single line item after the app itself. Budget for one thing when you’re going to need two and you’re short before anyone writes a line of code.

FAQ

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 is usually $30,000–$55,000: several jobs people do at a desk, more than one kind of account, and the reports somebody currently builds by hand. 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, not 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 won’t, 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’s two products. The admin side is routinely described in one sentence and priced at zero, and it’s 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’s calendar time nobody can staff their way out of.