What a Custom Web App Actually Costs (And Why Quotes Vary 10x)

If you have collected three quotes for the same web application and they came back at $18,000, $70,000 and $240,000, you are not doing anything wrong. That spread is normal, and it is almost never a straightforward story of one vendor being cheap and another being greedy.

It usually means three teams read the same brief and built three different products in their heads.

The three realistic tiers

Published industry estimates cluster fairly consistently. Cleveroad, SaM Solutions and others put simple apps in the $10-60K band and enterprise platforms above $200K, and that broadly matches what the market actually transacts at.

Tier	Typical range	What it buys	Timeline
Focused build	$15K-60K	One clear job done well - internal tool, MVP, portal with 5-10 core screens	6-14 weeks
Mid-sized platform	$50K-150K	Multi-role SaaS, marketplace, customer portal with integrations and billing	3-7 months
Enterprise	$200K+	Compliance, SSO, audit trails, high availability, legacy integration	6-18 months

The bands overlap deliberately. A $55,000 project could be an ambitious focused build or a stripped-back mid-sized one, and which it is depends entirely on how much you are willing to cut.

What actually moves the number

Scope, and specifically the parts nobody discussed. Authentication is the classic example. “Users can log in” is a week. “Users log in via their company’s SSO, with role-based permissions, an audit log and SCIM provisioning” is six weeks. Both get written as login in a brief.

Integrations. Every external system you connect to is a source of unpredictable cost. A documented, modern REST API might be two days. An undocumented internal system reached through a legacy SOAP endpoint that nobody at your company still understands is a genuine unknown - and the honest quote for it is a range, not a number.

The quality bar you are actually buying. Test coverage, error monitoring, CI/CD, documentation and accessibility work typically add 20-35% to a build. They are also the difference between an app that can be handed to another team in year two and one that has to be rewritten. Cheap quotes very often exclude all of it without saying so.

Team location. US and Western European agencies commonly charge 2-3x Eastern European, LATAM or Indian rates. This is real and it is not automatically a quality difference - but it does change what else you are buying, particularly timezone overlap and how much of your own time the project consumes.

Design. A build using an existing design system is materially cheaper than one that includes research, wireframes, visual design and iteration. If a quote seems low, check whether design is in it at all.

Why the same brief produces a 10x spread

Here is the uncomfortable mechanic: the vaguer your brief, the wider the quotes - and the cheapest quote is usually the one that understood the least.

A vendor who has spent two hours with you will quote against a small, clean mental model. A vendor who has spent two days will have found the reporting requirement, the second user type and the data migration, and will quote against all three. The second number is higher and more likely to be what the project actually costs.

This is why comparing quotes on price alone systematically selects for the least-informed vendor. The low bid wins, then discovers the same complexity three months in, and the difference reappears as change requests - usually at a worse rate than if it had been scoped up front.

The fix is not to demand firmer prices. It is to make the brief specific enough that vendors are quoting the same thing.

Making quotes comparable

Before you request estimates, write down:

• User roles, and what each one can and cannot do
• Every external system the app must talk to, with links to their API docs
• Data volume and migration - what exists today, where it lives, how much
• Non-negotiable compliance requirements - SOC 2, GDPR, HIPAA, data residency
• What “done” means - is a test suite expected, is documentation expected, who hosts it

Then ask each vendor for the same three things: a fixed price for discovery, a breakdown by feature area rather than a single number, and an explicit list of what is excluded. The exclusions list is the most informative document in the entire process.

If a vendor will not break down the number, that is data too.

What you should actually receive

A surprising number of disputes come from the two parties having different ideas about what “the project” included. Agree these explicitly before signing:

The running application, deployed somewhere you control, with the deployment process documented well enough that someone else could repeat it.

Source code in your repository, under your organisation’s account - not the vendor’s, transferred at the end. This sounds obvious and is a recurring cause of pain.

Credentials and ownership of every third-party service created for the project: hosting, database, email provider, error monitoring, domain registrar. Services registered under a vendor’s personal account are a real business risk.

Documentation sufficient for handover - architecture overview, environment setup, deployment steps, known limitations. Not exhaustive, but enough that a new developer is productive in a day rather than a fortnight.

Test coverage on the critical paths. Not 100%, which is a poor use of budget, but the flows where failure costs money.

If any of these is absent from a proposal, ask whether it is excluded or assumed. Both answers are informative.

Red flags in a quote

Some signals reliably predict trouble, and they are visible before you sign.

A precise number from a vague brief. “$47,500” from a one-page brief means someone guessed with false precision. An honest early estimate is a range, or a fixed price for discovery followed by a range.

No exclusions listed. Every real project has exclusions. A proposal without them has either not been thought through or is planning to bill the gaps as change requests.

Hourly billing with no cap and no estimate. Fine for ongoing work with an established partner, dangerous for a first project. You are absorbing all the estimation risk from a party with better information than you.

No mention of maintenance. A vendor who never raises ongoing cost is either inexperienced or letting you find out in year two.

Timelines with no dependency on you. Every real project needs decisions, content, access and sign-off from the client. A plan that does not name what it needs from you has not been planned.

Substantially cheaper with no explanation. Sometimes it is genuine - lower cost base, existing components, a genuinely simpler read of the problem. Ask which. If the answer is not specific, the difference will reappear later.

Reducing the cost honestly

There are legitimate ways to spend less, and they all involve buying less rather than paying less.

Cut scope to one workflow. By far the largest lever, and the subject of MVP scoping.

Use an existing design system rather than commissioning bespoke design. Frequently 15-25% of a project.

Accept a platform. Building on an established platform rather than from scratch removes a large amount of undifferentiated work - the argument in build versus buy.

Defer the admin interface. For low user counts, a generic admin tool or direct database access costs nothing and defers a meaningful chunk of build.

Supply your own content and data. Migration and content preparation are real line items, and they are work you can do internally.

What does not reduce cost sustainably: removing tests, skipping error monitoring, or choosing a vendor purely on price. Each defers spending rather than avoiding it, usually at a worse rate.

The cost most people forget

Budget 15-25% of the build cost per year for the application’s continued existence. Dependency updates, security patches, hosting, third-party service fees, browser changes and small feature work.

Skipping this does not save money - it defers it. An unmaintained application accumulates security debt and dependency drift until a routine change becomes a rewrite, and the rewrite costs more than five years of maintenance would have.

Any vendor who does not raise ongoing cost during the sales conversation is either inexperienced or is letting you discover it later.

Is a custom build even the right answer?

The cheapest web app is the one you do not build. Before committing to any of these numbers, it is worth running the build versus buy decision honestly - a good chunk of custom builds are solving problems an existing product already covers at a fraction of the cost.

That calculation has genuinely shifted recently. AI-assisted development has compressed the cost of certain categories of build, particularly internal tools and integration glue, which changes where the build/buy line sits. We covered what has actually changed and what has not separately, because a lot of the claims in that area do not survive contact with production.

And if you are a founder rather than an enterprise buyer, the numbers above are the wrong frame entirely - you should be scoping toward an MVP with a fixed timeline, not a feature list.

Fixed price, time and materials, or phases?

The pricing model shifts risk between you and the vendor, and each is right in different circumstances.

Fixed price transfers estimation risk to the vendor, who prices that risk in - typically a 20-40% buffer. It works when scope is genuinely well understood, which in practice means after discovery. Offered before discovery, it either means the vendor is guessing or has padded heavily, and it makes changing your mind expensive because every adjustment becomes a commercial negotiation.

Time and materials is honest about uncertainty and gives you flexibility to change direction, which on a real project you will. The risk sits with you, so it requires either trust or a cap. It suits ongoing work and exploratory builds badly suited to fixed scope.

Phased fixed price - fixed price per clearly defined phase, re-quoted at each boundary - is usually the best structure for a first engagement. You get budget certainty in reasonable increments, the vendor is not pricing a year of unknowns, and you have a natural exit point if the relationship is not working.

The pattern worth avoiding is uncapped time and materials with a vendor you have not worked with, on a brief neither party has examined closely. That combination puts all the risk on the party with the least information, which is you.

A reasonable process

1. Write the specification above. It takes a day and it is the highest-leverage day in the project.
2. Pay two or three vendors for a short paid discovery. It is far cheaper than choosing wrong.
3. Compare the breakdowns, not the totals.
4. Choose on how well they understood the problem, then negotiate price.
5. Budget 20% annually from day one.

The goal is not to find the cheapest quote. It is to find the quote whose assumptions match reality - because that is the only one that will still be true in month four.