How much does it cost to build a web app? For a small or mid-sized business, it comes down to hours times a rate. The hours are decided mostly by how many distinct screens the app has, and by a few features behind them: logins and user roles, connections to systems you already run, the admin side your team works in, and payments. After launch there's a much smaller monthly bill to keep it running, plus maintenance.
You won't find a price list here. The ones online disagree with each other by tens of thousands of dollars, and none of them show where their numbers come from in a way you can check. We build these apps and run the projects ourselves, from the first estimate to launch, so what we can do is show you what the number is made of. Then you can read any quote you get and tell whether it makes sense.
What are you actually paying for?
Mostly people's time. A custom web app is discovery (working out what it has to do), design, development, testing and launch, with project management running through all of it. Each phase is hours, and the estimate is those hours multiplied by a rate. Software licences and hosting are usually a pretty small part of the build cost by comparison.
That sounds obvious, but it's useful, because it tells you what to ask for. A quote that gives one number for "the app" is hard to judge. A quote that splits the hours by feature and by phase lets you see where the money goes, and lets you take a feature out and see what it saves.
Discovery is the phase people most want to skip, and we think that's a mistake, because it's the least expensive place to change your mind. In a meeting, changing a requirement is just a conversation, but once the screens are built somebody has to redo work you've already paid for.
What does a developer's hour cost in the US?
Public wage data gives you a reference point. The Bureau of Labor Statistics puts the median US software developer's salary at $135,980 a year as of May 2025, which works out to roughly $65 an hour over a standard 2,080-hour year. For web developers, the median was $92,650.
Those are wages, though, not what anyone bills you. A firm's rate sits above them because it also pays for benefits, a project manager, testing and all the hours nobody can bill. The BLS puts the median for web developers and digital designers at $47.85 an hour, so if a US quote works out to less than what a developer is typically paid, it's worth asking who is doing the work and where.
In practice, the rate is the part of the quote you can do least about. The hours are where you have control, and that's what the rest of this post is about.
Which features drive the cost up?
Start with the screens, though not with how many pages there are. What counts is how many different layouts the app needs, since each one is designed, built and tested on its own, and a page that reuses one costs very little. So a site with 10 layouts and 10 pages can cost more than one with 5 layouts and 1,000 pages.
The rest of the hours go into the logic behind those screens, and especially the cases where something goes wrong. These are the features that move an estimate the most:
- Logins and user roles. With one kind of user this is pretty simple. But once your staff and your clients each need to see different data, every screen needs rules about who can see and change what, and every rule needs testing.
- Integrations with systems you already use. Connecting to your CRM, accounting software or a supplier's API can easily be the biggest single line in the estimate. The connection itself is often quick, but handling bad data and outages, and records that don't match on both sides, is what takes the time. Our API integration work is mostly that part.
- The admin side. Somebody on your team has to manage users and fix records, and sooner or later someone will want an export. It's easy to forget about until late in a project, and on some apps it ends up nearly as big as the part your customers see.
- Payments. Turning on card payments with a processor like Stripe doesn't take long. Then someone asks for a refund, a card fails on renewal or a subscription changes mid-month, and every one of those has to reconcile with your books, which is where the hours actually go.
- Reports and dashboards. A plain table of records doesn't cost much, though charts and filters that match how your managers actually look at the business usually take longer than anyone planned.
- Importing your existing data. If the app replaces spreadsheets or an old system, that data has to be cleaned and moved. It's a project of its own; our website migration checklist covers the database side of it.
Accessibility and speed belong on the list too, though they cost less when they're built in from the start. Retrofitting either one later means going back over screens that were already finished, the same way a slow website is harder to fix after launch than to build fast.
But the part that most often turns out bigger than the client expected isn't on that list at all. It's the database design. Most people would name logins and permissions as the heavy features, or billing with subscription tiers. Those can grow out of scope too, but not every app has them. Nearly every app has a database, and it usually ties into all of those features. So extra scope on any one of them can mean changing the database schema (how the data is structured and linked) as well.
Is an MVP enough?
For a first version, usually yes. An MVP (minimum viable product) is the smallest version that does one job well enough for real people to use: one main workflow, one or two kinds of user, and only the integrations it can't work without. Everything else waits until you've seen how people actually use it.
The point isn't to spend less for the sake of it. It's that the second half of a feature list is mostly guesses, and you'll guess better after a few months of real use. We'd rather a client spend the second half of the budget on what their users asked for than on what seemed important in the first meeting.
When we scope one, we actually start from the other end, with the whole product. Before talking about cuts, we want to understand the client's business model and where they want the app to end up, and we work out the full feature set it would have if nothing were cut. Only then do we step back and ask what the core of it is. The Pareto principle is a useful way to put it: which fifth of the features covers four-fifths of what users need? We're pretty relentless with that trim, because every feature that stays in pushes the launch further out.
There are two limits on cutting, though. The first version still has to be viable: if it keeps breaking, or causes problems for the business it's supposed to help, it isn't an MVP. And it should be one step in a roadmap, with the next steps defined before launch. Those will likely change once feedback and analytics come in from real users, but it's still better to start from a vision that holds together than to decide each release as it comes.
What does a web app cost to run each month?
The services usually come to tens of dollars a month before usage and payment fees, on paid plans, not free ones. On top of that comes maintenance, which is mostly time. A small business app on a common modern stack (a Next.js app on Vercel, with Supabase for the database and logins, and Stripe for payments) looks roughly like this as of October 2026:
| Line item | Example service | What it costs |
|---|---|---|
| Hosting | Vercel Pro | $20 a month per developer seat, with $20 of usage included |
| Database, logins and file storage | Supabase Pro | From $25 a month, including 100,000 monthly active users |
| Card payments | Stripe | 2.9% plus 30 cents per successful domestic card charge, no monthly fee |
So the fixed part can start around $45 a month for one seat, before usage. Payment fees scale with sales: on a $100 charge, Stripe keeps $3.20. Other stacks (AWS, a managed WordPress back end, a different database host) price things differently, so treat this as an example of the order of magnitude rather than a recommendation.
And don't run a business app on a free tier, because Vercel's free Hobby plan is for personal, non-commercial use, and Supabase pauses free projects after a week with no activity, which is the last thing you want for an app your clients log into.
The running cost people tend to forget is time. Security updates and keeping dependencies current have to happen whether anyone asks for them or not, a connected service will change its API at some point, and once your team is using the app they'll have small changes. So it makes sense to plan for some hours every month, not just for the build.
That's also why setting up hosting on its own usually isn't enough. Someone has to deal with it when the hosting misbehaves, and the architecture needs upgrading as the framework and the services under it move on. We offer ongoing hosting and maintenance packages for clients, where you have access to a developer for support, and we handle the hosting troubleshooting and keep the architecture maintained and upgraded.
Fixed price or time and materials?
Both can work, and they protect different things. A fixed price protects your budget, but only for the scope written down, so everything outside it becomes a change request. Time and materials (paying for the hours actually worked) protects your flexibility, but the total moves with every decision.
So a fixed price is really only as good as the scope written behind it. If the scope is vague, the firm either pads the number to cover the risk or argues with you about every change later, and neither is great. Time and materials works well when you trust the team and get regular, honest reports on hours against the estimate.
Either way, we'd insist that a change request comes back as a written estimate of the extra hours and the effect on the launch date before anyone starts on it.
Should you build a custom app at all?
Not always. If an off-the-shelf tool already does most of what you need, configuring it almost always costs less than building, and someone else pays for its upkeep. A custom app pays off when the workflow itself is what sets your business apart, or when you're stitching together so many tools that the glue costs more than an app would.
There's also a middle option people overlook: keep the tools you have and connect them. A couple of integrations, say between your CRM and your accounting software, can remove most of the copy-and-paste without a new app at all.
If you've already got a quote and you're not sure whether to build, buy or connect, we also review estimates and architectures as advisers through our consulting service.
How to get an estimate you can trust
Bring three things to the first conversation: the workflow you want the app to handle, step by step, the people who will use it and what each of them needs to do, and the systems it has to connect to. A rough sketch of the screens helps too, mainly to show how many different layouts there are. Together, those decide most of the hours.
Then look for a quote that breaks the hours down by feature and by phase, says what's out of scope, and explains how changes are priced. If it does that, you can compare it with others line by line, and you'll know which features to cut if the total is too high.
The web applications we build are things like client portals, internal workflow tools and systems for managing inventory or documents, for businesses in Los Angeles and across the US. If you're planning one, tell us what it needs to do and we'll give you an estimate that shows where the hours go.
