Asking what a web app costs is like asking what a house costs: it depends on size, location and finish. But unlike a vague answer, the factors that drive software cost are specific. Once you know them, you can judge estimates, compare proposals and control your budget.
We do not publish price lists, because two apps with the same number of screens can differ hugely in effort. This guide explains why, and what to do about it.
What really drives the cost
Effort, and therefore cost, grows with a handful of factors:
- Workflows. Each distinct task users perform, such as booking, approving or invoicing, needs screens, logic and tests.
- Business rules. Pricing logic, approval chains, deadlines and exceptions often take more effort than the screens around them.
- User types and permissions. Each role that sees different data or actions adds design, code and testing.
- Integrations. Every connected system, such as a CRM, payment provider or accounting tool, adds work, and poorly documented ones add risk.
- Data migration. Moving and cleaning existing data is frequently underestimated.
- Design depth. A clean standard interface costs far less than a highly custom, brand-driven one.
- Non-functional needs. High security, audit trails, offline use, many languages or heavy traffic all add effort.
How complexity changes the budget
It helps to think in levels rather than numbers:
- Simple: one user type, a few workflows, standard design, one or two integrations. Examples include internal request trackers and simple portals.
- Moderate: several user types, a dozen workflows, meaningful business rules, a handful of integrations. Examples include booking systems and customer portals with payments.
- Complex: many roles, complex rules, multi-tenant SaaS design, many integrations, high security or scale. Examples include platforms that serve many businesses.
Moving up a level typically multiplies effort rather than adding a little. The biggest savings come from keeping the first version at the lowest level that solves the problem. See how to plan a SaaS MVP.
The most underestimated items
In our experience, a few items cause most budget surprises:
- Integrations with systems whose APIs are limited or poorly documented.
- Data migration from spreadsheets or old systems with inconsistent data.
- Permissions that turn out to be more detailed than first described.
- Reporting, which is often added late and touches everything.
- Edge cases in business rules that nobody wrote down.
A clear brief reduces all of these. See how to write a software requirements document.
How the team model affects cost
Hourly rates vary widely by country, seniority and company. But rate is only half of the equation. A senior team that makes good decisions early often costs less overall than a cheaper team that needs rework. AI-accelerated teams can also deliver the same scope with fewer hours, especially on routine work. See how AI changes software development cost.
Costs beyond the build
The build is only part of the total. Budget for:
- Hosting and infrastructure. Servers, databases, storage and backups.
- Third-party services. Email sending, maps, SMS, AI APIs and payment fees.
- Maintenance. Security updates, dependency upgrades and small fixes.
- Support and improvements. Most apps keep evolving after launch.
Ignoring these makes a cheap build expensive over three years. Neglecting maintenance also creates technical debt that raises the cost of every later change.
How to get an estimate you can trust
A reliable estimate usually comes in two steps. First, a rough range from a written brief, with assumptions listed. Second, a short paid discovery phase that turns the brief into workflows, wireframes and a technical plan, followed by a detailed estimate. Discovery costs a small fraction of the project and removes much of the uncertainty.
When comparing proposals, ask each team for:
- What is included and excluded.
- The assumptions behind the number.
- Which parts are most uncertain and why.
- How changes are handled and priced.
- What ongoing costs to expect after launch.
Ways to keep costs under control
- Start with the smallest version that solves the core problem.
- Use proven services for payments, email and sign-in instead of building them.
- Decide quickly when the team asks questions. Waiting costs money.
- Review working software every week or two, so problems are caught early.
- Keep a separate list for new ideas, and add them in later phases.
Fixed price or time and materials
How you contract affects both cost and risk. Fixed prices suit small, well-defined work. Time and materials suits evolving products, with regular checkpoints and a budget cap. Many projects use a mix: a fixed-price discovery, then time and materials for the build. Read fixed scope vs time and materials for the details, and how long it takes to build an app for timelines.
Putting it together
Start from the business case: what the app should save or earn over a few years. Then work backward to a first version whose cost is clearly justified, with a plan for what comes next if it succeeds. That keeps spending tied to results, and it makes every later decision easier, because you know what the software is worth to you.
An example of how scope drives cost
Imagine two booking apps that look similar on paper. The first lets customers pick a time, pay a deposit and receive a confirmation. The second does the same, but also handles several locations with different opening hours, staff with individual schedules, packages that combine services, discounts with rules, a waiting list and a sync with an external calendar.
Both apps might have a similar number of screens. The second one will cost several times more, because every extra rule interacts with the others and each needs to be designed, built and tested. When you review an estimate, look for these interactions, not just the list of pages.
Thinking in value, not only cost
The right budget depends on what the app is worth to your business. If manual work costs your team two days every month, or if the app enables a new revenue stream, you can estimate the value over two or three years. That number tells you how much it makes sense to spend and how quickly the investment should pay back. It also helps you decide which features are worth building now and which can wait. See how to measure ROI for a method that also works for software projects.
Finally, remember that the cheapest project is the one that solves the right problem the first time. Time spent on a clear brief and a focused first version is almost always the best money in the budget.