“How much will our web application cost?” has the same honest answer as any software question: it depends on decisions about what the application must do. This guide explains those decisions so you can see which ones move the effort, and make them on purpose. It does not quote prices — a number without your scope behind it would not help you.
Workflows, not pages
A web application is measured by what people do in it, not by how many screens it has. List the jobs it must support — “a customer books an appointment”, “a manager approves a request”, “the finance team exports invoices” — and the rules around each one: who may do it, what happens when something goes wrong, what has to be recorded. Each workflow needs design, building, data and testing, and the rules are usually where the effort hides.
Users, roles and the admin side
Most business applications have more than one kind of user: customers, staff, managers, administrators. Each role sees different screens and has different permissions. The admin side — managing users, content, settings and reports — is easy to forget in early estimates and is often as large as the customer-facing part.
Data and reporting
What the application stores, how long it keeps it and how it is searched or reported on all shape the work. Importing existing data from spreadsheets or an old system is a task of its own. Dashboards and exports are valuable, but each report has to be designed, built and checked.
Integrations
Connecting to other services adds work in proportion to how many there are and how well documented they are:
- payments and invoicing;
- email and notifications;
- maps, calendars and file storage;
- existing business systems such as an ERP, CRM or accounting software.
Each integration needs to handle failures and changes on the other side, so name them in the estimate.
Design and experience
An internal tool used by a handful of trained staff needs less design work than a product sold to the public. SaaS products, customer portals and anything people choose to pay for need flows, screens and a design system that make them easy to learn. Designing first, before building, usually saves cost overall, because changes are cheaper in a design than in code.
SaaS-specific work
If the application will be sold by subscription, add the parts that make that possible: sign-up and onboarding, accounts for separate customer organisations, plans and billing, and the tools your team needs to support customers. These are separate pieces of work from the product’s core features.
Testing, security and quality
Testing each workflow, including the unhappy paths, is part of building it. So is security: authentication, permissions, protecting personal data and keeping dependencies up to date. Budget for these from the start rather than as a final phase.
Hosting and running costs
A web application needs hosting, a database, backups, monitoring and domain and email services. These are ongoing costs, and they grow with usage. After launch there are also updates, fixes and improvements; plan for the second year as well as the first release.
Getting an estimate you can rely on
The most useful input is a short description of the first release: who uses it, the few workflows it must support, the integrations it needs and what exists today. With that, a team can give an estimate with its assumptions written down, and you can see exactly what would change it. A first release that does a few things well, followed by planned next releases, is the most reliable way to keep cost under control.