What a custom web application actually costs — and where the money goes

Ask three agencies what a custom web application costs and you will get three wildly different numbers, none of which come with an explanation. That is frustrating if you are the one paying, and it makes it almost impossible to tell whether you are being quoted fairly or simply being guessed at.

This post breaks down where the money actually goes. Not to justify any particular price, but so you can read a quote critically and ask better questions.

Why nobody gives you a straight number

Software pricing feels evasive because the thing being priced is genuinely not fixed. “A booking system” can mean a single-page form that emails you a request, or a multi-tenant platform with payment processing, staff scheduling, automated reminders, and a customer portal. Those differ by an order of magnitude in effort, and both are honestly described by the same three words.

The useful response to a vague quote is not to demand a firm number. It is to force the scope into the open. A quote you can interrogate is worth more than a low one you cannot.

The five things that actually drive cost

1. How many distinct user journeys exist

Not screens, journeys. A customer who browses, selects, pays, and receives confirmation is one journey. An administrator who reviews orders, issues refunds, and exports reports is another. Each journey needs designing, building, testing, and handling when it goes wrong.

Applications tend to grow in journeys rather than pages, and this is where estimates most often break down. Adding an “admin view” sounds like a small request. It is frequently a third of the project.

2. How much of it is genuinely custom

A great deal of what software does is solved. Authentication, payments, file uploads, email delivery, search — all have mature, well-tested components that can be assembled rather than written. A good team reaches for these by default.

Cost accumulates where your requirements diverge from the well-trodden path. A standard checkout is cheap. A checkout with tiered pricing that varies by customer contract, partial shipments, and a bespoke approval step is not, because none of that can be bought off the shelf.

Worth asking any prospective partner: which parts of this are you building, and which are you assembling? If the answer is “building everything,” find out why.

3. What it has to talk to

Integrations are consistently underestimated, by clients and agencies alike. Connecting to a well-documented modern API is a day or two of work. Connecting to a fifteen-year-old accounting system with no documentation, inconsistent behaviour, and a support contact who answers weekly is a different proposition entirely.

The cost is rarely in writing the integration. It is in handling the cases where the other system is down, slow, or returns something nobody anticipated — and in the discovery work needed before anyone can even estimate honestly.

4. How much traffic and data it must survive

An internal tool used by twelve people can be built simply, and it should be. Complexity that exists to serve scale you do not have is waste.

Applications serving significant public traffic need caching strategies, database indexes designed deliberately, background job processing, and monitoring that tells you something is wrong before your customers do. That work is real, it is invisible from the outside, and skipping it is why some cheap applications collapse in their first busy week.

Be honest about your actual requirements. Paying for scale you will never reach is as wasteful as building something that falls over.

5. Whether anyone will maintain it

Software is not a purchase, it is an ongoing commitment. Dependencies release security patches. Browsers change. Payment providers deprecate old APIs and eventually switch them off. An application nobody touches for two years is not stable — it is quietly accumulating risk.

A quote that excludes maintenance is not cheaper. It has simply moved a cost off the page.

What a quote should contain

Regardless of the number, a quote worth taking seriously should tell you:

• What is explicitly excluded. The exclusions reveal more than the inclusions. Vague scope on paper becomes an argument later.
• Who owns the code and the infrastructure accounts. The answer should be you. If the hosting, domain, and repository sit in the agency’s name, changing partners becomes an expensive negotiation.
• What happens when requirements change. They will. A sensible process for handling that beats a fixed price that both sides quietly know is fictional.
• What the first month after launch looks like. Real usage always surfaces problems. Someone needs to be responsible for them, and that should be agreed before launch rather than after.

The cheapest quote is often the most expensive

This sounds like something an agency would say, so treat it sceptically. But the pattern is consistent and easy to explain.

An unrealistically low quote is usually built on optimistic assumptions — that requirements are complete, integrations behave, nothing changes. When those assumptions fail, the project either runs over, or corners get cut in places you cannot see: no tests, no error handling, no documentation, credentials pasted where they should not be.

You do not discover this at handover. You discover it six months later when something breaks and the next developer quotes a substantial sum to understand what exists before they can change anything.

The genuinely expensive outcome is not a high quote. It is paying twice.

How to get a number you can trust

If you want an estimate that means something, help make one possible:

• Describe the problem before the solution. “Staff spend two days a month reconciling orders by hand” is far more useful than “we need a dashboard.” It leaves room for a cheaper answer than the one you had in mind.
• Say what already exists. Current systems, spreadsheets, and workarounds are the real specification. They show how the business actually operates rather than how it is described.
• Separate must-have from would-like. Most projects contain a smaller project that delivers most of the value. Finding it early is worth real money.
• Consider paying for a short discovery phase. A few days of paid scoping that produces a specification you own — and can take to other agencies — will beat any free estimate. It also tells you a great deal about how a team thinks before you commit to a full build.

The short version

Cost tracks scope, integration complexity, scale requirements, and maintenance commitment. Any of those left undefined is not a saving — it is an unpriced risk that surfaces later.

If you are weighing up a project and want a straight answer about what is involved, get in touch. We would rather tell you a project is smaller than you think than sell you something you do not need.