How much does a custom web application cost?

A custom web application costs what it takes to build, test and run it, and that effort is set by a handful of drivers: how many features and user roles it has, which outside systems it connects to, how much existing data has to move in, how custom the design is, how thoroughly it is tested, and what hosting and maintenance it needs after launch. Two applications that look alike on a screenshot can differ widely in effort. The way to get a number you can trust is a written scope that lists features, integrations and exclusions, with the estimate broken down against it.

This article goes through each driver, explains why it moves the cost, and ends with the questions that separate a reliable estimate from a guess. It gives no price figures on purpose: rates vary by country, team and stack, and an average would mislead you more than it would help.

#Why there is no honest single price

A web application is a set of decisions. "A customer portal" can mean a login and a page of invoices. It can also mean self-service ordering, approvals, document uploads, notifications and an admin area with an audit log. Both are called a portal. Each extra decision adds screens, rules, tests and edge cases, and the edge cases usually take longer than the main flow. A quote given before those decisions are written down is a guess about which version you meant.

#What drives the cost of a web application

Scope and features

Count the things a user can do, and the rules behind each one. A plain search box is quick to build. A search with filters, saved queries and results that respect each user's permissions is a different job. Features that look small on a wish list, such as export to Excel, content in several languages or a history of changes, each need design, code and tests.

User roles and permissions

Every role multiplies the work. When customers, staff, managers and partners each see different data and can change different things, every screen and every API endpoint has to check who is asking. Single sign-on, two-factor login and approval chains add more. Roles are cheap to plan early and expensive to retrofit, because permissions touch almost every part of the code.

Integrations

Payment providers, accounting software, ERP and CRM, booking systems, couriers and email services each come with their own API, test environment, limits and failure modes. The effort depends mostly on the quality of each one. A well-documented API with a sandbox is predictable. An old system with no documentation, or one that exchanges CSV files over FTP, can take longer than the rest of the feature. A reliable integration also needs retries, logging and a way to reconcile records when the two systems disagree.

Data migration

If the new application replaces an old one, the data has to come across: customers, orders, products, files, and sometimes user passwords, which may need to be reset if the old system stored them in a format the new one cannot check. Old data is rarely clean. Duplicates, empty fields and formats that changed over the years all need rules, and a migration is usually rehearsed several times before the real switch. Early estimates often leave this work out.

Design

A proven component library styled with your brand is the fastest route. A fully custom interface, with its own components, animations and responsive layouts for every screen, costs more to design and more to build. Accessibility work and a multilingual interface add to both.

Testing and quality

Automated tests on the critical paths, such as payments, logins and anything that changes data, cost time up front and save it every time the code changes afterwards. Manual testing across browsers and devices, load testing for the traffic you expect, and a security review all belong in the estimate if you need them. If an estimate has no line for testing, ask where it went.

Hosting, monitoring and maintenance

The application has to run somewhere after launch. Shared hosting, a virtual server and a managed cloud platform each have different running costs and need different amounts of administration. On top of hosting come backups, error tracking, uptime monitoring, security updates for the framework and its libraries, and the small changes your business will ask for. Budget for this as an ongoing cost, because the first release is only the start of the application's life.

Driver	Lower effort	Higher effort
User roles	One or two roles that see the same data	Several roles, per-record permissions, approvals
Integrations	Documented APIs with a sandbox	Legacy systems, file exchanges, no test environment
Data migration	A new system with no existing data	Years of data from several sources
Design	A component library with your branding	Custom components and motion on every screen
Testing	Automated tests on critical paths	The same, plus load testing and a security review

#How to get an estimate you can trust

A trustworthy estimate is tied to a written scope. Before you compare numbers from different suppliers, check that each one describes the same application. A useful scope document contains:

• the user roles, and what each one can see and do;
• the main features, written as things a user does;
• every integration, with the system's name and the data that flows each way;
• which data will be migrated, and from where;
• the design approach and the languages the interface needs;
• the testing included, and where the application will be hosted;
• an explicit list of what is out of scope.

The last item matters most. Two estimates that differ widely often describe two different projects, and the list of exclusions shows you where.

#Questions to ask about any estimate

• Is it broken down by feature? A single total hides where the effort goes and leaves you nothing to cut if the budget is tight.
• What assumptions does it rest on? For example, that the payment provider has a sandbox, or that your team supplies the content.
• Is it a range, and why? Unknowns such as an undocumented API justify a range. Ask what would narrow it.
• What happens when the scope changes? Changes are normal. Find out how they are estimated and approved before the first one arrives.
• When will you see working software? Regular demos let you catch a misunderstanding while it is still cheap to fix.
• Who owns the code, the accounts and the documentation? If they are not in your name, moving to another supplier later will cost more.

The pricing model shapes your risk as much as the number does. We compare the two common models in fixed price or time and materials: which model fits your project.

#How to lower the cost without cutting quality

• Start with the smallest version that does the core job for real users, and add the rest in later releases.
• Use proven building blocks for common parts such as logins, admin screens and email, and spend custom work where your business is different.
• When you have a choice of partner, prefer the one with a well-documented API.
• Clean your data before the migration starts. You know it better than any developer.
• Answer questions quickly. Time spent waiting for a decision costs as much as time spent writing code.

Cutting tests, documentation or security updates lowers the first invoice and raises every one after it, so keep them in the plan.

#How PN Scripts can help

PN Scripts builds custom web applications in any stack, and every project starts with a written scope and estimate that states what is included and what stays out. Nothing starts until you have read it and said yes. You can see how the work is organized on our custom web development page.