What a Custom Web App Costs, and Why

If you ask four developers what a custom web application costs, you will get four answers, and they may be an order of magnitude apart. That is not because three of them are lying. It is because "web application" describes a suitcase and a shipping container with the same word.

This article is an attempt to explain what actually moves the number, so that when you do get quotes you can tell which ones are comparable — and so you can work out roughly which size of project you have before anyone quotes you at all.

What you are actually buying

A custom application is not a thing that exists somewhere and gets installed. It is a sequence of decisions written down in a form a computer will execute. Most of the cost is in making those decisions correctly, not in typing them.

Broadly, the money goes into five places:

1. Working out what it should do. The single most underestimated line. Every "obvious" process has three exceptions that only come up when someone tries to write the rule down.
2. The screens people use. Every form, list and dashboard has to work for a real person on a real device, with the mistakes real people make.
3. The data model underneath. How your customers, jobs, invoices and users relate to each other. Get this wrong and everything built on top costs more forever.
4. The parts nobody sees but everybody assumes. Logins, permissions, hosting, backups, tests, monitoring. Skipping them is how a cheap quote becomes an expensive year.
5. Proving it works. Testing, fixing, and watching it under real use after launch.

A quote that looks dramatically cheaper than the others has usually removed items 1, 4 or 5. Sometimes that is a legitimate choice. It should at least be a visible one.

The five things that move the number

How many kinds of user there are. One internal team is the simplest case. Staff plus customers is roughly double the work, because every screen now needs a second version and every piece of data needs a rule about who may see it. A third role — contractors, managers, an administrator — adds again.

How many systems it has to talk to. A self-contained app is predictable. Anything that has to exchange data with a payment provider, a calendar, an accounting package or an industry system is less predictable, and the difference between a well-documented interface and an undocumented one can be weeks.

Whether data has to move from somewhere else. Migrating years of history out of an old system is its own project. The data is always messier than anyone remembers.

How much the rules branch. "Approve the order" is cheap. "Approve the order unless it is over a threshold, or the customer is on hold, or it is a Tuesday in the billing cycle" is not. Each branch is design, build and testing.

How clear the requirements are on day one. Not a small factor. Ambiguity is the most expensive material in software, because it gets discovered late.

If you want a rough sense of where your own project sits before you speak to anyone, count these five. Two roles, no integrations and rules you can state in a paragraph is a different animal from four roles, a migration, and an industry system nobody has documented.

The three sizes we work in

We size projects into three bands. The bands exist so a conversation can get to a useful number quickly, and so nobody pays for a process bigger than their project. Each band has a typical duration in working time, and what each one includes is set out on our services page.

Small — about one to two weeks. A marketing site, a single-feature tool, or one focused internal application: one kind of user, one process, no integrations or one simple one. Suits a business replacing a single spreadsheet, or putting a credible site in front of an existing business.

Medium — about three to five weeks. The most common shape: more than one type of user, real logins and permissions, a dashboard that answers the question you keep asking, and one or two integrations. Suits a business whose main operational process has outgrown email and shared files.

Large — about six weeks and up. Several user types, multiple connected processes, migration from an existing system, or integrations that have to be reliable rather than merely present. We always precede a project this size with a paid discovery, because quoting one from a conversation is guessing.

Two honest caveats about any figure you are given, by us or by anyone else. A price quoted before anybody has understood your process is a starting point, not a prediction — the real number belongs in a written scope, and at our end every number comes in writing before any money moves. And a duration is working time, not elapsed time: projects wait on decisions, content and access, and the fastest ones are those where somebody on your side can answer a question the same day.

Why a discovery sprint beats a confident guess

When a project is large, vague, or has to connect to something nobody has looked at yet, there are only three things a developer can do: guess high, guess low, or find out.

Guessing high means you pay for the risk whether or not it materialises. Guessing low is worse — it produces a number designed to win the work, followed by a change request for everything that was not in it. That is where most horror stories come from, and it is usually not malice. It is arithmetic done too early.

Finding out is a short, paid piece of work, typically one to two weeks. It ends in written requirements, an outline of how the system will be built, and a fixed quote for the build itself. You own all of it. If you decide not to proceed with us, you can take that document to anyone else and get quotes that are finally comparable, which is rather the point.

If you go ahead with us afterward, the discovery sprint's fee is credited against the project, whatever its size.

How payment usually works

We bill a deposit at signature, a payment at the mid-project milestone, and the balance at acceptance. Work starts when the deposit arrives. Hosting and service costs — the database, the servers, email delivery — are separate from the build and are quoted in the proposal before you sign.

After launch, most applications move onto a monthly retainer covering hosting management, monitoring, security updates and a set number of hours for changes. Software is not finished when it launches, and budgeting for it monthly is far cheaper than treating every change as an emergency.

Four questions to ask anyone quoting you

1. What is not included? The good answer is specific.
2. What happens when we find something we both missed? Everyone finds something. You want to know the process before it happens.
3. Who owns the code, and where does it live? Get this in writing.
4. What does it cost to keep running, per month, after launch? A build price without a running cost is half a quote.

We do not publish figures, because a number attached to a project nobody has understood yet is worth very little to you and commits us to something we have not seen. What we do instead is give you a real one quickly: describe the project and you get a size band and an honest answer, usually on the first call.

Get an estimate. If it is too vague to price honestly we will say so rather than invent a number, and propose a discovery sprint instead.