Ask five development teams to quote the same web application and you can get numbers that differ by a factor of ten. Founders often read that spread as proof that software pricing is arbitrary, or that someone is trying to take advantage of them. Usually it is neither. The spread comes from each team interpreting an ambiguous brief differently, quoting a different scope, and pricing in a different amount of risk.
This guide breaks down what actually drives web app development cost, what broad price bands look like for an MVP versus a full product, how the two common pricing models shift your risk, and which costs never appear in the initial quote. The aim is to help you read proposals critically and plan around numbers that hold up.
The five cost drivers that explain most of the variance
When we scope projects in our custom web development practice, five factors account for most of the difference between a cheap build and an expensive one.
- Scope and workflow complexity. Screen count is a weak proxy for cost. What matters is the number of workflows and their edge cases. A form that saves a record is trivial; a form with an approval chain, email notifications, partial saves, and an audit trail is a week of work, not an afternoon.
- Integrations. Every third-party system — payment gateway, CRM, accounting software, shipping API — adds not just the happy path but error handling, retries, webhooks, and sandbox testing. Modern, well-documented APIs integrate quickly; legacy systems with poor documentation can consume weeks on their own.
- Design complexity. A clean interface built on an established component library costs a fraction of a fully custom design language with bespoke interactions, animation, and data visualization. Both can look professional; only one requires a designer and a front-end engineer working in lockstep for weeks.
- Authentication and roles. Simple email-and-password login is close to a commodity now. Multi-tenant products with role hierarchies, granular permissions, and single sign-on multiply the testing surface, because every feature must be verified against every role.
- Compliance and data handling. GDPR obligations, health or financial data, audit logging, and encryption requirements shape the architecture itself, not just the feature list. Compliance added late costs several times more than compliance designed in from the start.
Two projects that sound identical in a sales call can sit at opposite ends of all five dimensions. That, more than anything else, is why quotes vary.
Typical price bands: MVP versus full product
Treat the following as broad market observations rather than quotes — rates vary widely by region, team seniority, and how the engagement is structured.
- Simple MVP (one core workflow, standard auth, minimal integrations): often low five figures with a freelancer or very small team, mid five figures with an established agency.
- Substantial MVP (multiple user roles, a couple of integrations, payment processing): commonly mid to high five figures.
- Full production product (multi-tenant SaaS, several integrations, polished UX, compliance requirements): typically low six figures and up, delivered over multiple phases.
Very cheap quotes usually mean one of three things: the vendor has misunderstood the scope, plans to cut corners on testing and error handling, or intends to make the money back on change requests. Very high quotes from large consultancies often include process overhead your project may not need. Neither extreme is automatically wrong — but you should be able to see, line by line, what the money buys.
A quote is only as accurate as the scope behind it. Send a vague brief and you will get either a wide range or a confident number that will not survive contact with reality.
Fixed price versus time and materials
Fixed-price contracts feel safer, and for well-defined projects they can be. But a vendor can only fix a price by fixing the scope, which requires a detailed specification up front and a change-request process for everything outside it. Vendors also pad fixed prices to cover their own risk — you pay for uncertainty either way, just less visibly.
Time-and-materials means you pay for the hours actually worked. It suits products that will evolve as you learn from users, which describes most startups. The trade-off is that you carry the budget risk, so insist on controls: weekly demos, a prioritized backlog you own, and a monthly cap you approve in advance.
The hybrid many experienced teams prefer is a short fixed-price discovery phase that produces a real specification and estimate, followed by fixed milestones or capped time-and-materials for the build. You spend a little up front to make the big number trustworthy.
The costs that will not be in the quote
The build price is the beginning, not the total. Budget for:
- Maintenance. A common rule of thumb is 15–25% of the build cost per year for dependency updates, security patches, bug fixes, and small improvements. Software that receives zero maintenance degrades — libraries deprecate, browsers change, vulnerabilities surface.
- Hosting and infrastructure. Modest at launch — often tens to a few hundred dollars per month — but it grows with traffic and data. Managed databases, file storage, and monitoring each add line items.
- Third-party fees. Payment processors take a percentage of every transaction. Email, SMS, and AI API usage are metered. Some services have generous free tiers that jump sharply at scale — read the pricing page for the tier above the one you need today.
- Your own time. Someone on your side must review demos, answer questions, test releases, and make decisions quickly. Slow feedback loops quietly extend timelines, and extended timelines cost money.
How to get a quote you can actually plan around
Before requesting quotes, confirm that custom is the right call at all — for some problems, configuring an existing product is cheaper and faster, and we have a separate guide on deciding between custom and off-the-shelf software. If custom wins, do the following:
- Write a one-page brief: who the users are, the three to five core workflows, every system the app must integrate with, and a clear split between must-have and later.
- Ask each vendor to itemize their assumptions and state what is explicitly excluded. The exclusions list tells you more than the headline number does.
- Compare scopes, not totals. Two quotes covering different scopes are not competing bids, no matter how the prices line up.
- For anything nontrivial, pay for a scoping or discovery phase first. It converts guesses into an estimate with foundations, and it is far cheaper than discovering the real scope mid-build.
Want a realistic number for your project?
We are glad to give you a plain-spoken assessment — including telling you when a smaller build, or no custom build at all, would serve you better. Send your brief through our contact page and we will come back with itemized assumptions, not just a figure.