How much does a web app cost to build

Every “how much does a web app cost” article gives you a range and calls it an answer. The range is real, and it’s also nearly useless, because the width of it is the whole story. Here’s what actually moves the number.

The five questions that matter more than feature count

1. Does it need to handle money? Adding Stripe subscriptions or one-off payments sounds like a checkbox. Doing it properly means webhook verification, one source of truth for who has access to what, and handling upgrades, downgrades, failed cards and cancellations. That’s real scope, not a checkbox.

2. Does more than one type of user exist? A single-user tool and a multi-tenant SaaS product look similar in a demo. They are not similar to build. The moment you have organizations, teams or roles, your data model and your security model both get harder, and that difficulty compounds with every feature added afterward.

3. Does it need real-time behaviour? Live updates, notifications, anything happening without a page refresh, adds infrastructure a static CRUD app doesn’t need.

4. What does day one actually require, versus month six? The biggest cost driver we see isn’t the tech. It’s building month six’s features into day one’s launch, because “we might need it” felt safer than deciding. Every unused feature is scope you paid for and are now also maintaining.

5. Who’s going to touch this code after us? An app one developer will maintain forever can take shortcuts a team-maintained product can’t. Documentation, consistent patterns and test coverage cost time up front and save far more of it later, but only if someone’s actually going to be reading that code in a year.

Rough shapes, not quotes

These are shapes, not prices, because your answers to the five questions above move any of them by multiples:

• A focused single-user tool: the smallest real category. One kind of user, no payments, no real-time behaviour.
• A SaaS product with accounts and billing: the common shape for a first paid product. Multi-tenant from day one, Stripe, an admin view.
• A platform with real complexity: multiple user types, integrations with other systems, workflows that branch based on role or state.

Anyone giving you a number before understanding which shape you’re in is quoting a different project than the one you’re about to build.

Why AI builders changed the first number, not the real one

Lovable, Bolt and similar tools make the frontend and a basic backend fast to stand up, which has genuinely lowered the cost of getting to a working demo. What they haven’t changed is the cost of the parts that make a demo into a product: a data model that holds up under real usage, security that survives an audit, and integrations that don’t fall over under load. Several of our full-stack projects start exactly here, taking a fast AI-built prototype and building the production layer underneath it.

What a fixed quote should follow, never precede

Scoping first, then a fixed price with named milestones. A quote given before scoping is a guess dressed as a number, and it tends to be wrong in the direction that costs you money later: either it was padded to survive the unknowns, or it was optimistic and the gaps show up as change orders once work has already started.

What to bring to a scoping call

Answers to the five questions above, whatever mockups or notes exist even if rough, and a real budget range. A vague budget doesn’t protect you from a bad quote. It just means nobody involved, including you, can tell whether a number is reasonable.