8 min readpricingweb-applicationsscoping

How Much Does a Custom Web Application Cost? A Builder's Breakdown

Ask three dev shops what a custom web application costs and you will get three non-answers. "It depends." "Anywhere from ten thousand to half a million." "Let's get on a call." All three translate the same way: the shop either does not know its own cost structure, or knows it and will not commit before it has measured your budget.

The number is knowable. Custom web application cost is a function of a short list of drivers, and anyone who builds for a living can price those drivers inside a band. This is the breakdown Norseson uses to do it.

Why "it depends" is a lazy answer

"It depends" is true the way "the weather depends" is true. It depends on named variables. A builder who cannot name the variables has not priced enough projects. A builder who can name them but will not is negotiating, not scoping.

Note what is missing from the list below: page count, number of screens, and which JavaScript framework is in fashion this quarter. Those correlate weakly with cost. The expensive parts of a web application are the parts that never appear in a screenshot — permission checks, failure handling, data cleanup, integration retries.

The six drivers that actually move the number

1. Authentication complexity

Email-and-password through a managed provider is close to free. The number moves when you add SSO against a customer's identity provider (SAML is a week of work, not an afternoon), enforced multi-factor policies, session rules like "idle admins log out in 15 minutes but field techs stay signed in for a 12-hour shift", or account linking across login methods. Auth is also where a cheap mistake becomes a breach. It is the wrong line item to award to the low bidder.

2. Roles and permissions

Two roles — admin and user — cost almost nothing. Per-object permissions cost real money: this manager sees these accounts, that contractor sees only jobs assigned to them, the bookkeeper sees amounts but not customer notes. That is a data-model decision that touches every query in the system, and retrofitting it costs roughly double what designing it in costs. If you hear yourself saying "and some users should only see part of it", that sentence is worth $5k–20k and belongs in the scope document, not in a week-nine conversation.

3. Integrations

Price integrations individually, never as a lump. A well-documented API that pushes webhooks: $2k–5k each. A poorly documented API, or one you must poll and reconcile because it has no webhooks: $5k–15k. A legacy on-prem system with no API at all: start at $15k and commit to nothing before discovery. An integration is not done when data flows once in a demo. It is done when it survives the other system being down, slow, or wrong — and that second half is most of the cost.

4. Data migration

If the application replaces spreadsheets or a legacy tool, the old data has to move, and migration is the most reliably underestimated line in the industry. Duplicate customers. Columns that quietly changed meaning in 2023. Free-text fields that were secretly categories. Dates in three formats. Working rule: when real data exists, migration costs 10–25% of the build. A quote that omits the line has not omitted the work. It has deferred the argument.

5. Offline and mobile requirements

"Works on a phone" is responsive layout. Cheap. "Works in a warehouse with no signal and syncs when the truck gets back in range" is a distributed-systems problem: conflict resolution, sync queues, stale-data states a user can understand. The first is a rounding error; the second can double the project. Say which one you mean before anyone quotes anything.

6. Compliance and audit

HIPAA, SOC 2 alignment, immutable audit trails ("who changed this record, when, and what was the value before"), retention and deletion rules. Compliance work is mostly invisible: logging, access control, encryption decisions, deletion workflows that actually delete. Depending on the regime it adds 15–40%, and none of it can be sprinkled on after launch.

Constraint

The bands below assume a senior independent builder or a small senior studio at 2026 North American rates. Large-agency pricing runs 2–4x for the same scope. Offshore rates run lower and can be excellent — the bands compress, but the drivers do not change.

The bands

$8k–15k — a focused internal tool. One core workflow. A handful of users. Simple roles, one integration or none, auth through a managed provider. Deployed, monitored, documented. This band is real, but only when the scope is genuinely narrow: it buys the tool that replaces one painful spreadsheet, not "a small CRM".

$15k–50k — a production web application. Customer-facing or business-critical. A real permission model, two or three integrations, migration of existing data, and proper failure engineering: queues, retries, error states a user can act on, launch hardening. Most serious small-business and funded-startup builds land in this band. It is wide because the six drivers stack.

$50k–150k+ — a multi-tenant platform. Multiple organizations on shared infrastructure. Tenant data isolation, billing, admin tooling, onboarding flows, and uptime obligations backed by monitoring and an on-call answer. Cost here is dominated by failure modes: what happens when a webhook replays, when two tenants' data could touch, when a migration runs against live customers. If a platform quote comes in under $50k, the failure modes were not priced.

Phase pricing — and why discovery is fixed-price, first

Norseson prices in phases, and the process starts with discovery: a fixed-price, fixed-duration engagement — typically $2k–5k across one to two weeks — that produces a written scope. Workflows, data model, integration list, failure boundaries, and a build quote with each driver itemized.

Discovery is fixed and first for two reasons:

  1. It converts "it depends" into constants before either side commits to the large number. The build quote that follows discovery is a measurement, not a guess.
  2. The deliverable is portable. If the fit is wrong, the scope document is valid input for any competent shop. You are never buying a hostage situation for $3k.

A builder who quotes a five-figure build without something shaped like discovery is guessing. You pay for the guess either way: up front as padding, or later as change orders.

Build cost vs. carrying cost

The build number is not the total number. A web application that matters to the business carries:

  • Hosting and services. $50–500 per month covers most applications in the first two bands: compute, database, error tracking, backups, email delivery. Platforms run higher.
  • Maintenance. Dependencies rot. Browsers change. Integrated APIs deprecate endpoints on their schedule, not yours. Plan on 15–20% of the build cost per year to keep the system current and patched.
  • A response plan. Retainer, support agreement, or a named internal owner — someone specific who acts when the alert fires at 2 a.m.

Concretely: a $30k application costs roughly $35–40k across its first two years. If a proposal never mentions year one after launch, the headline number was marketing.

Red flags in the quote that looks too low

UNDERSCOPED_QUOTE

The quote prices the happy path only. Every screen assumes valid input, live integrations, and one user at a time. The missing 30–50% — error states, retries, permission edge cases, migration cleanup — is discovered mid-build and returns as change orders, billed at conflict pricing instead of quote pricing.

Specific signals the number is fiction:

  • No failure-state budget. Ask what happens when the payment webhook arrives twice. If the answer is a blank look, duplicates are not in the price. They will happen anyway.
  • No launch-hardening line. Backups, monitoring, alerting, a security pass, load sanity checks. Absent from the quote means absent from the system.
  • No migration line when you have existing data. See driver four.
  • Screens-based pricing. "$1,500 per screen" prices the one part of the application that was never the expensive part.
  • A fixed price with no written scope attached. A fixed price without a fixed scope is a fixed argument, scheduled for whichever week the assumptions collide.

Questions to ask any shop — including this one

  1. What is explicitly out of scope, in writing?
  2. What happens to the price when I ask for a small addition mid-build? The correct answer involves the phrase "change order", not the phrase "we'll absorb it".
  3. Which failure modes are in the budget — duplicate webhooks, a down integration, a bad deploy during business hours?
  4. What does handover include: code, infrastructure access, documentation? Could another team take over without you?
  5. What does year one after launch cost?

Cost is a scoping problem before it is a negotiation. Web application builds at Norseson start with fixed-price discovery for exactly that reason: by the time the build number is quoted, it should be boring.

Need a system built around these failure modes? That is the lab's work.