How much does a custom web app cost?

What are you actually paying for?

Every quote for a custom web app is the same arithmetic underneath: engineering hours multiplied by a rate. Senior engineering rates sit around $100–250 per hour in most markets, so the whole game is how many hours the thing takes — which is a question about scope, not about technology.

Those hours are not all coding. A build that goes well spends real time on the data model, on the exceptions nobody mentioned in the kickoff, on integrating with systems whose APIs were designed by someone with different assumptions, and on migrating whatever you are running now. Quotes that come in dramatically low are usually quotes that priced the screens and left those four out.

What moves the number most?

Four things do most of the moving, and none of them is the choice of framework.

How many roles and screens the tool needs. Roles are the expensive part, not screens. Two roles means every screen, every action, and every record has a permission question attached to it, and that question has to be answered consistently everywhere or the tool leaks data.

Whether the data model exists or has to be designed. If your records already live in a well-structured system, a large part of the thinking is done. If the real model lives in a spreadsheet with four colour conventions, designing it is the project — and it is the part that determines whether the tool still fits in two years.

How many systems it has to integrate with. Each integration adds an API to learn, credentials and rate limits to respect, failure handling for when the other side is down, and a reconciliation story for when the two sides disagree. Integrations are usually the largest single line in a quote that surprises people.

Whether data has to migrate out of what you run now. Moving history is its own project with its own risk, and it is worth pricing separately so you can see what it costs. That is a data-movement problem with its own discipline, not a footnote in the build.

Fixed price, hourly, or retainer — which costs less?

Fixed price is the right shape for a defined build: the scope, the number, and the milestones are agreed before anything starts, and the risk of an under-estimate sits with the person who made it. It requires discovery first, because a fixed price on an undefined scope is either padded or wrong.

Hourly suits work that genuinely cannot be specified in advance — an audit, a rescue, an integration against an undocumented system. It is honest for the unknown and dangerous for the known, because the incentive runs the wrong way once the scope is clear.

A retainer is for after launch, and it is the line most budgets forget. Tools that fit get used, tools that get used attract requests, and a standing block of engineering capacity is cheaper than re-negotiating a small project every time the workflow changes.

What does a quote usually leave out?

Hosting and infrastructure, first — modest for an internal tool, but not zero, and worth naming so it is not a surprise on the first invoice. Then the licences and API tiers of the systems being integrated, since some platforms charge for the API access an integration depends on. If you want the shape of those running costs before committing, the platform comparison priced at published rates puts real numbers on it.

The two that matter more are the ones nobody invoices for. Your team's time during the build is real: someone has to answer questions about the workflow, review the staging demos, and test the thing against reality, and a build with no available owner on the client side runs slower and lands further from the workflow. And the cost of the workaround you are living with today — the manual cross-referencing, the seats bought so occasional users can view a status — is the number the build is actually competing against. Most people compare a build to zero. It should be compared to that.

How do you keep the number down?

Cut roles before you cut features. A tool that starts with one role doing one workflow end to end can ship, earn its keep, and grow; a tool that starts with every role half-served does none of those things.

Be honest about which integrations are needed at launch and which are merely wanted. Get your data somewhere clean before migration rather than paying engineering rates to interpret it. And check first whether the tool you need is a better-configured version of one you already run — the build-versus-buy question is worth settling before the pricing question. If the answer is build, that is the shape of how I scope and price custom applications.

Questions