Custom Web Application Development: What It Costs to Build

A custom web application is software that runs in a browser and is built around one organisation's process rather than sold to many. The line between it and a website is not visual. A website publishes information; an application holds state, enforces rules and does work: accounts, permissions, records that change, and logic that has consequences when it is wrong.

That difference decides everything downstream: the cost, the timeline, the security obligations and who you should hire. This article covers where the line actually falls, what a build costs in 2026, and which parts of an estimate are real.

The practical test is whether the system has users who log in and data that changes as a result of what they do. A booking system, a dealer portal, an internal quoting tool and a claims workflow are applications. A brochure site with a contact form is not, even when it is beautifully engineered.

Three things separate the two in engineering terms. An application has authentication and authorisation, meaning it must decide not just who you are but what you may see. It has persistent state that multiple people modify concurrently, which brings in transactions, conflict handling and audit trails. And it has business rules that live in code rather than in a document, which is where most of the testing effort goes.

If none of the three applies, you are looking at a website, and you should not pay application prices for it.

Most companies arrive at this question through pain rather than strategy. A spreadsheet has become the system of record, three people email versions of it, and something expensive has already gone wrong. Four patterns come up repeatedly, and each is a legitimate trigger.

A spreadsheet is running a real process. Pricing, allocation, scheduling. It works until two people edit at once, or until the person who built the formulas leaves.

Customers ask for access to their own data. Order history, documents, project status. Emailing PDFs does not scale, and a portal is the usual answer. Our customer portal guide covers that specific case.

Two systems need a workflow between them. The ERP holds stock and the CRM holds customers, and a human retypes between them daily.

The off-the-shelf tool fits 70% of the process. The remaining 30% is where your margin lives, and no amount of configuration reaches it.

European agency pricing as of August 2026 starts around €12,000 for a genuinely small application and moves quickly from there. Unlike a website, the page count tells you nothing: what drives the number is the count of distinct user roles, the number of external systems involved, and whether the data is regulated.

A useful rule when reading quotes is that the first working version is roughly half the total cost. The other half is everything that makes it survivable: error handling, permissions edge cases, migration of existing data and the reporting nobody mentioned in the kickoff.

The cheapest way to control the number is to cut roles rather than features. Each additional user type multiplies the permission cases that have to be designed, built and tested, and it does so faster than a new screen does. A system with one role and twenty screens is routinely cheaper than one with four roles and eight screens. If a role exists only to view a report, ask whether an export would do for the first year.

Clients tend to picture the screens. The screens are perhaps a third of the work. Below them sit four layers that rarely appear in a proposal but always appear in the invoice, and knowing their names makes it much easier to read an estimate critically.

Data model and migration. Defining the entities and moving whatever already exists, usually a spreadsheet with inconsistent data that has to be cleaned before it can be imported.

Authentication and permissions. Roles, sessions, password recovery, and the matrix of who may do what. This is small to describe and large to test.

Integrations. Each external system is its own project: credentials, rate limits, error handling and a plan for when the other side is down.

Observability. Logging, alerting and a way to answer "what did the system do at 14:20 on Tuesday". Skipped in cheap quotes, then rebuilt after the first incident.

Testing sits across all four rather than after them. For an application the meaningful question is not whether the happy path works but what happens on the unhappy ones: a duplicate submission, a session that expires mid-form, two people editing the same record, an integration that times out halfway. Those cases are where money is lost in production and where thin quotes are thin.

Three to six months is normal for a first production version of a mid-sized application. The schedule slips for reasons that are predictable enough to plan around, and in our experience two of them account for most of the damage.

The first is discovery done by interview rather than observation. People describe the process they believe they follow. The real one has exceptions, and the exceptions are the requirements. Watching the work for a day finds them; a workshop usually does not.

The second is integration with a system nobody owns. The estimate assumes an API exists and is documented. Week six discovers it does not, and a vendor conversation now sits on the critical path.

Both are cheap to de-risk. A one-week technical spike before the estimate is fixed catches almost all of it.

Buying beats building most of the time, and any agency that tells you otherwise is selling. SaaS wins on price, on time to value and on the fact that someone else handles security patches. There are three situations where it stops winning, and they are worth naming precisely.

The process is the differentiator. If how you quote, route or price is why customers choose you, encoding it in a tool everyone else uses removes the advantage.

Per-seat pricing outgrows the build. At 200 users, €40 per seat per month is €96,000 a year. A build with a five-year horizon starts to look like arithmetic rather than ambition.

Data cannot leave. Residency, retention or sector rules sometimes rule out a shared platform outright, and GDPR obligations around processing and storage are easier to satisfy on infrastructure you control.

There is also a middle option that gets skipped too often. Many processes can be run on a configurable platform with a thin custom layer over it: the standard tool holds the records, and a small application handles only the part that is genuinely yours. It costs a fraction of a full build and it survives, because the vendor keeps maintaining the large half. Ask any agency to price that variant alongside the full build; a team that refuses to is not weighing your interests.

Portfolios show screens, which is the part that reveals least. Four questions separate teams who have operated software from teams who have only shipped it, and none of them is technical enough to need a developer in the room.

"Show me something you still maintain." Building is easy; living with a decision for three years is the skill.

"What did you get wrong on the last project?" A team without an answer either has not shipped enough or is not being straight with you.

"Who owns the code and the infrastructure accounts?" The answer should be you, in writing, including repository access from day one.

"What happens when we stop working together?" Documentation, handover, credentials. According to the Stack Overflow Developer Survey, technical debt is consistently the most cited frustration among professional developers, and a chunk of it is inherited systems nobody can explain.

Security is not a feature to add later, and treating it as one is how a €30,000 project becomes a €30,000 project plus an incident. The baseline is not exotic, and a competent team includes it without being asked.

The OWASP Top 10 is the reference the industry actually uses: broken access control, injection, misconfiguration and the rest. Ask whether your build addresses it, and ask what testing proves so.

Beyond the baseline, cost rises with obligation. Personal data means retention rules, export and deletion. Payments mean you should not be storing card data at all. Regulated sectors mean audit trails and evidence. Expect 10% to 20% on top of a general build where any of these apply, and treat a quote that shows no such line as one that has not thought about it.

One obligation is easy to forget because it is not technical: someone has to keep applying updates after launch. A dependency with a published vulnerability is only a risk if it stays unpatched, and that is an operating commitment rather than a build one. Name the person or the contract that owns it before you sign, because this is the single most common way a well-built application becomes an insecure one.