The short answer
The cost of a custom web application is set mainly by how many kinds of user it has, how many record types it manages, how many rules decide what happens to those records, how many other systems it connects to, and how much existing data must come across, plus the quality bar for security, availability and support.
The number of screens is a weak proxy. Two applications with twenty screens each can differ by a factor of ten if one has three roles and no integrations and the other has eight roles, approval chains and two-way ERP sync.
We don’t publish price lists, because a number without scope is the thing that makes quotes incomparable. After a short discovery we give a range for your scope with the assumptions written down.
What you are paying for
A web application is a system of eight parts. Every proposal is a statement about how much of each it includes, whether it says so or not.
| part | what drives the effort |
|---|---|
| User experience | Number of distinct screens per role, complexity of forms and tables, accessibility and device support |
| Business logic | Calculations, eligibility, pricing and validation rules, and their exceptions |
| Data | Record types, relationships, history, search and reporting needs |
| Roles and permissions | Number of roles, per-record and per-organization rules, audit requirements |
| Workflow | States, transitions, approvals, deadlines and notifications |
| Integrations | Number of systems, direction of data, real-time versus batch, quality of their APIs |
| Backend | Background jobs, queues, scheduled processes, performance needs |
| Infrastructure | Environments, availability targets, backups, monitoring, compliance hosting |
The cost drivers
These are the levers that move a budget most, with what “less” and “more” look like for each.
| driver | lower effort | higher effort | why it costs |
|---|---|---|---|
| Roles | Two or three roles with clear boundaries | Many roles, per-organization permissions, delegated admin | Every role multiplies screens, rules and tests |
| Record types | A handful with simple relationships | Dozens, with history, versions and complex relationships | Each needs storage, forms, lists, search and migration |
| Workflow | Linear states, one approval | Branching states, approval chains, SLAs, exceptions | Exceptions are where defects hide; they need explicit design |
| Integrations | One system, read-only or batch | Several systems, two-way, near real-time | Mapping, error handling, retries, monitoring, vendor quirks |
| Data migration | Starting fresh or one clean source | Several messy sources that must reconcile | Cleaning and proving data is often underestimated |
| Security and compliance | Standard practices | SSO, audit trails, data residency, regulated data | Design, documentation and evidence for auditors |
| Interface | Standard components, desktop-first | Highly custom interactions, offline use, many devices | Design and front-end time per screen |
| Reporting | Operational lists and exports | Dashboards, scheduled reports, data warehouse feeds | Reporting needs its own data design |
Scope your own application
Count these five things for the application you have in mind. The counts describe scope in a way any supplier can estimate against, and they are the first things we ask about in discovery.
| count this | your count | why it matters |
|---|---|---|
| e.g. customer, customer admin, ops, manager, finance | Each role adds screens, permissions and test cases. | |
| e.g. request, order, invoice, asset, supplier | Each brings fields, relationships, lists, search and history. | |
| count states plus rules like “manager approves over $5k” | Rules and exceptions are where most logic and testing goes. | |
| count two-way integrations twice | Each needs mapping, error handling, retries and monitoring. | |
| spreadsheets, old databases, other tools | Cleaning and reconciling data takes longer than moving it. |
scope profile
Enter your counts to see a rough scope profile. This is a way to describe scope, not a price.
Typical shapes of project
Most web applications fall into one of these shapes. Their effort is set by different drivers, which is why the same budget conversation goes differently for each. If your project is a CRM rather than a general web application, see the custom CRM development cost guide.
shape 1
A focused internal tool
One workflow, a few staff roles, one integration. Replaces a spreadsheet or an e-mail process. Effort is dominated by getting the rules right. Internal tools
shape 2
A customer portal over existing systems
Customers and their admins, several areas, two to four integrations. Effort is dominated by integrations and the security model. Customer portal development
shape 3
A multi-tenant SaaS product
A core feature plus tenancy, billing, onboarding, roles and an operator console. Effort is dominated by platform plumbing and the tenancy model. SaaS development
shape 4
A marketplace
Three applications (buyer, seller, operator) and money moving between them. Effort is dominated by payments, payouts and trust. Marketplace development
Costs after launch
The build is not the whole cost. Plan for these from the start:
- Hosting and environments: production, staging, backups and monitoring.
- Third-party services: e-mail and SMS, payments, identity, maps, search, error tracking. Many are usage-priced.
- Maintenance: security patches, dependency and framework upgrades, so the application never becomes a legacy system. See web application maintenance.
- Support and small changes as people use it and the business changes.
- Licences for any commercial components or APIs the application depends on.
Reducing cost without cutting corners
- Phase by workflow, not by layer. Ship one complete workflow first, rather than all the screens without the logic. A smaller first release is what MVP development is for.
- Buy the commodity parts. Identity, payments, e-mail and billing are better bought than built.
- Integrate rather than rebuild. Use the systems you already pay for as systems of record where they are good at it.
- Decide data migration scope early. Migrating five years of history versus open records only can be the biggest single variable.
- Standardise the interface where users won’t notice, and invest in the few screens people use all day.
How to compare proposals
Before comparing totals, check that the proposals describe the same thing:
- Is the scope expressed in roles, records, rules and integrations, or only in screens and features?
- Is each integration named, with the direction of data and who provides API access?
- Is data migration included, and from which sources?
- Are environments, automated tests and deployment included, or extras?
- What is assumed about design: wireframes, full UI design, accessibility?
- Who owns the code, infrastructure accounts and documentation at the end?
- What support and maintenance is included after launch, and what does it cost?
- Which assumptions, if wrong, would change the price most?