How to Estimate the Cost of a Custom Web Application
A step-by-step worksheet for estimating custom web app cost: scope, effort ranges, your own rates, contingency, running costs and comparing quotes fairly.
How to estimate it: the short answer
List what the application must do, size the effort for each item as a range, multiply by the day rates you are actually quoted, add contingency in proportion to how uncertain each item is, and then add the monthly cost of running it. The result is your estimate, with every assumption visible, so you can compare suppliers on the same basis. This guide gives you that worksheet. It deliberately quotes no prices: the published averages are not reliable enough to plan with, for reasons explained below.
This is for custom web applications: portals, internal tools, marketplaces and SaaS products where users sign in and the system stores their data. If you are not sure that is what you need, start with custom website vs web application. For brochure and marketing sites, the website development cost guide covers the relevant factors.
Key takeaways
- Cost is scope × effort × rate, plus contingency, plus running costs. Estimate each part separately.
- Size effort as a range (low, likely, high), not a single number.
- Use the rates you are quoted, not published averages.
- Let contingency come from your uncertainty, item by item.
- Running costs continue for the life of the application. Estimate them monthly.
- Compare quotes only after putting them on the same assumptions.
Why published "average cost" figures mislead
Search for web application cost and you will find confident ranges with no stated method. The more careful datasets explain their limits, and the limits are the point:
- Marketplace review data. Clutch's web development pricing page says it compiles its figures "from first-party reviews submitted by verified web development clients". That is useful context, but the sample is self-selected, the projects range from small sites to large builds, and the page's headline "typical" project figure and its average project figure are far apart and describe different things.
- Government rate cards. The UK's Digital Outcomes and Specialists framework (DOS7, RM1043.9) publishes average day rates for digital specialists. They are averages of the maximum rates suppliers may charge under the framework, as at 28 June 2022, based on a 7.5-hour day and excluding VAT and expenses. Some rows contain what appear to be placeholder maximum values. They are not prices paid, and they are not project costs.
- Salary surveys. Developer salary data tells you what employment costs, not what a supplier charges or what a project needs.
- Agency tier tables. Tiers such as "simple, medium, complex" with price bands rarely define what goes in each tier, so you cannot place your own project in one.
Worth noting
None of these sources measures what a project like yours costs. That is why this guide asks you to build the number from your own scope and quotes.
What drives the cost
Before the worksheet, know which features move effort most. Each of these multiplies screens, rules or test cases. Integrations are often the least predictable line; scoring each third-party API integration separately makes the estimate more honest.
| Driver | Why it adds effort | Question to settle before quoting |
|---|---|---|
| User roles and permissions | Every role needs its own views and rules, and each rule needs testing | How many roles, and what can each see and do? |
| Integrations | Each external system has its own API, errors and changes | Which systems, which direction, how often, and who owns the API keys? |
| Payments and bookings | State must stay correct through failures, refunds and retries | Which provider, which flows (one-off, subscription, refunds)? |
| Data migration | Old data is rarely clean or well structured | How much data, from where, and how messy? |
| Reporting and admin | Often underestimated; admins need search, filters and exports | What must staff see, edit and export? |
| Compliance and security | Privacy duties, audit logs, security testing | Which data protection rules apply, and is any data sensitive? |
| Design depth | Custom interface design and user testing take time | Is a well-built standard interface enough, or is the experience the product? |
| Uncertainty | Unclear requirements expand during the build | Which items do you not yet understand well? |
Step 1: Scope inventory
List every capability as a row, in plain language. Group rows into user journeys ("a customer places a repeat order") and supporting pieces ("staff export monthly orders"). Include the parts people forget: sign-up and account recovery, admin screens, email notifications, error states, data import, and the privacy notice and consent flows your market requires.
For each row, record the role that uses it, any integration it touches, and an uncertainty rating: S if you could describe it precisely today, M if you know the outcome but not the details, L if you are unsure what it should do. The rating is about how well the item is understood, not how big it is. A written requirements document is the natural home for this list.
| Journey or capability | Role | Integration | Uncertainty (S/M/L) | Must-have for launch? |
|---|---|---|---|---|
| Customer signs up and verifies email | Customer | Email service | S | Yes |
| Customer places a repeat order | Customer | Payment provider | M | Yes |
| Staff approve orders over a limit | Staff manager | None | M | Yes |
| Orders sync to accounting software | System | Accounting API | L | Later |
| Admin exports monthly report | Admin | None | S | Yes |
Pro tip
The rows above are an illustration of the format. Replace them with your own. If the list grows beyond what you can launch with, cut it using a riskiest-assumption-first approach to MVP scope before estimating.
Step 2: Size effort as ranges
Give each row three effort estimates in person-days: low (everything goes well), likely, and high (the realistic bad case). Do this with whoever will build it, or ask each supplier to fill in the same columns. Single-number estimates hide risk; ranges show it.
Expect the gap between likely and high to be wide on L-rated items and narrow on S-rated ones. If an L item has a narrow range, someone is guessing optimistically. Remember that effort covers more than coding: design, testing, code review, deployment and project management all take time, so either include them per row or add them as separate rows.
| Row | Low (days) | Likely (days) | High (days) | Gap (high − likely) |
|---|---|---|---|---|
| Your row 1 | … | … | … | … |
| Your row 2 | … | … | … | … |
| Design, testing, deployment, management | … | … | … | … |
| Total | Σ low | Σ likely | Σ high | Σ gap |
Step 3: Apply your own rates
Multiply the likely total by the day rate you have been quoted. If the team mixes roles (designer, developer, tester, project lead), use each role's rate for its share of the days. If you have no quote yet, leave the rate as a blank to fill in, rather than borrowing a published average: a number you cannot defend will anchor every later conversation.
Build estimate = Σ likely days × your blended day rate. Write down the assumptions next to it: which rows are included, who does the work, and which taxes or expenses are excluded.
Step 4: Add contingency from your uncertainty
Contingency is not a fixed percentage. It is the money that covers the difference between likely and high on the items you are unsure about. A simple method: add the gap column for all M and L rows and multiply by the rate. That is your contingency line. It will be large if your list has many L items, and that is information, not bad news.
The cheapest way to shrink contingency is to resolve uncertainty before the build. A short technical discovery phase turns L items into M or S by answering the open questions: what the integration's API actually allows, what the data looks like, how the approval rules work.
Key takeaway
Total build budget = build estimate + contingency. If that total is too high, cut scope or resolve uncertainty. Squeezing the effort estimates only moves the overrun to later.
Step 5: Estimate running costs
A web application costs money every month it is live. List each line, find the current price on the provider's own pricing page for your expected usage, and record the date you checked. The links below are examples of pages to check, not recommendations, and their terms change. For a line-by-line view of hosting bills by architecture, see how much it costs to host a web application.
| Running-cost line | What to check | Example page to check |
|---|---|---|
| Database and backups | Storage, backup retention, point-in-time restore, region | Your hosting or database provider's pricing page |
| Hosting and compute | Whether the plan allows commercial use, team seats, usage limits and overage charges | Vercel pricing (vendor; its Hobby plan is described as for personal, non-commercial use); Netlify pricing (vendor) |
| Email and SMS | Per-message charges for sign-in codes, receipts and notifications in each country you serve | Your email or SMS provider's pricing page |
| Third-party services | Payment fees, maps, search, file storage, analytics | Each provider's pricing page and fee schedule |
| Monitoring | Error tracking and uptime alerts | Your monitoring provider's pricing page |
| Security | Periodic security testing and dependency updates | Quotes from testers; maintenance scope |
| Maintenance and support | Hours per month for fixes, updates and small changes; response times | Your supplier's retainer terms |
Worth noting
For what a maintenance agreement should cover, see software maintenance contracts. The scope and response-time questions apply in any market.
Comparing quotes on the same assumptions
Send every supplier the same scope inventory and ask them to return it with their effort ranges filled in. Then check each quote against this list:
- Is every row from your inventory priced, and are any rows marked as excluded?
- Are design, testing, deployment and project management included, and where?
- What is the testing approach, and does it include access-control and authentication testing?
- Which uncertain items have they assumed away, and what happens if the assumption is wrong?
- Is it fixed price, time and materials, or a mix? What triggers a change request?
- What support is included after launch, and for how long?
- Who owns the code, repository, hosting account, domain and third-party accounts?
- Which running costs are included, and which will you pay directly?
- Are taxes and expenses included?
Pro tip
A quote that is much lower than the others usually has a different scope, not a better rate. Find the rows they assumed away before choosing on price. The guide to commissioning custom software in the UK covers contract points such as IP and acceptance that apply in most markets.
Hypothetical example: a distributor's reorder portal
This example is hypothetical. A distributor wants trade customers to reorder online. Its inventory has twelve rows. Ten are rated S or M. Two are rated L: the sync with its accounting software and customer-specific pricing.
When the founder asks the shortlisted team to size the rows, the two L items have the widest ranges, and together they account for most of the gap column. Instead of accepting a large contingency, the founder pays for a short discovery that inspects the accounting API and the pricing rules. Afterwards, one item becomes M and the other is moved to a second release. The contingency line shrinks because the uncertainty has shrunk, and the founder sends the revised inventory to two more suppliers for comparable quotes.
Risks and limits of this method
The worksheet is only as good as the inventory. Missing rows are the most common source of overruns, so ask a technical reviewer to read the list for gaps. Effort estimates from a team that will not build the product are less reliable than estimates from the team that will. And an estimate is not a commitment: requirements change once real users arrive, so plan a budget for the first months after launch as well as for the build.
If your project is small enough that one existing SaaS product covers it, this level of estimation is unnecessary. Price the subscription and the setup instead.
Conclusion and next steps
Build your estimate in five layers: scope inventory, effort ranges, your own rates, contingency from uncertainty, and monthly running costs. Send the same inventory to every supplier and compare their answers row by row. Where the uncertainty is high, pay to reduce it before you commit the full budget. For delivery practice after you have chosen a supplier, the custom software development guide covers discovery, testing and maintenance in more depth.
If you would like a team to size the build against your inventory, our web application development service starts from a written scope.
Want a scoped estimate with the assumptions written down?
ZSpace Labs is a remote-first technology studio that works with clients globally on custom web applications and product and UX design. If useful, we can go through your scope inventory, fill in effort ranges against it and list every assumption, so you can compare our estimate with others on the same basis.
Sources
Rate data and its limits: Clutch: web development pricing guide (marketplace data, updated 21 September 2026); GCA: Digital Outcomes and Specialists 7 (RM1043.9); DOS7 Lot 3 average day rates file.
Running-cost examples (vendor pages, checked but not quoted): Vercel pricing; Netlify pricing.
Accessed 14 October 2026. Vendor prices and plan terms change; check each provider's current page before budgeting.
Common questions.
Because no reliable public figure exists. The published numbers come from self-selected reviews, supplier rate cards or agency marketing, and they mix projects of very different scope. A figure that ignores your scope is more likely to mislead you than help. The worksheet gives you a number based on your own requirements and the rates you are actually quoted.