A custom web app costs what its scope requires, and five things set that scope: how many user roles it has, whether it takes payments, how many outside systems it connects to, whether it updates in real time, and what regulations apply. A single-purpose tool sits at the low end. A multi-sided, realtime product sits at the high end.
We run several web apps of our own, and they are not the same size of project. Not close. What separates them is what will make your quote higher or lower than you expected, so we would rather explain that than quote an average that means nothing.
CoverageCobra, our marketplace for attorneys who need a court appearance covered, is the most heavily engineered thing we run. It has two kinds of user, payouts through Stripe Connect, realtime matching, text and push alerts, and a test suite that must pass before anything merges. A screener that asks six questions and shows a result is also a web app. The distance between those two is the whole subject of this post.
How much does a custom web app cost to build?
A custom web app is priced by scope, not by screen count. The cost follows the number of user roles, the way money moves, the outside systems it must talk to, whether it needs realtime updates, and the rules it must comply with. Fewer of those means a smaller budget.
We do not publish prices, because every project is quoted on its own. What we can do is show you the drivers, so you can look at your own idea and see which end of the range it sits on before you talk to anyone.
One point up front: a web app is a different purchase from a website. If you are not sure which you need, read website vs web application first. Many ideas that arrive as apps turn out to be websites with one good form.
What drives the cost of a web app?
Five things drive the cost of a web app: user roles, payments, integrations, realtime behavior, and compliance. Each one adds screens, rules, failure cases, and tests. An app with one of them is a modest project. An app with all five is a large one, whatever it looks like on the surface.
- Roles. Every kind of user is close to a separate product. CoverageCobra serves posting attorneys and covering attorneys, and the operator needs a third view to oversee both. Regulars has a counter kiosk for staff and a dashboard for the owner. Each role needs its own screens and its own permission checks.
- Payments. A single charge through a hosted checkout page is simple. Subscriptions add renewals, failed cards, and cancellations. Paying out to other people, as a marketplace does, adds onboarding and verification for everyone who gets paid. See how to add payments to a web app.
- Integrations. Each outside system is a contract you do not control: text messages, email, calendars, e-signature, a register. Each needs error handling for the day it is slow or down.
- Realtime. If two people looking at the same thing must see changes instantly, the app needs live connections and rules for what happens when two actions arrive in the same second.
- Compliance. When a regulator or court sets requirements, they become features. Our defensive driving school platform is written to a court's requirements for such schools, with identity checks and certificates, and it goes live only when the court approves it. Check which rules apply to your own industry before scoping.
What does each budget range typically buy?
Our contact form asks for one of four budget ranges. Each range tends to fit a certain kind of project, described in the table below. These are broad bands, not prices, and every project is quoted on its own after we understand what it has to do.
| Budget range | What typically fits |
|---|---|
| Under $5,000 | A single-purpose tool: one kind of user, a few screens, no payments or one simple hosted checkout. A screener, a calculator, an internal form that saves to a database. |
| $5,000 to $15,000 | A focused app with sign-in, one or two roles, a dashboard, and one or two integrations such as email and a one-time payment. |
| $15,000 to $50,000 | A multi-role product with subscriptions or more involved payments, several integrations, notifications, an admin area, and automated tests. |
| Over $50,000 | Marketplaces with payouts, realtime features, regulated workflows, or software a whole business runs on every day. |
A project can sit in a lower band than its ambition suggests if the first version is cut well. That is what an MVP is for, and we cover how to cut one in what an MVP is and what yours should include.
What costs continue after launch?
A web app keeps costing money after launch in three ways: hosting and the database, the outside services it uses, and the developer time to keep it updated and fix what real users uncover. Budget for all three before you build, not after.
Outside services usually bill by usage. Text messages, email, payment processing, and AI calls each carry their own fees, set by those providers. A design that sends fewer messages or makes fewer calls is cheaper to run every month.
Maintenance is the one owners forget. Dependencies need updates, browsers change, and users find cases nobody imagined. CaseCobra runs a law firm day to day. Software like that cannot wait a week for a fix.
How do you lower the cost without ruining the product?
You lower the cost of a web app by removing drivers, not by squeezing the ones that remain. Launch with one role instead of three. Use a hosted checkout page. Connect one outside system. Skip realtime until users ask for it. Keep security, backups, and testing.
A few cuts that usually cost nothing in quality:
- Rent the hard parts. Payments, email delivery, and sign-in are solved problems. Paying a provider is cheaper than building them.
- Do the rare task by hand. If something happens twice a month, an admin can do it manually until volume justifies a screen.
- Write a clear brief. Vague requests get padded quotes. Our guide to writing a software project brief shows what developers need to price accurately.
What not to cut: the tests around money and permissions. Those are the bugs that cost more than the build.
Frequently asked questions
Why do quotes for the same app vary so much?
Because each developer is pricing a different imagined product. A two-sentence request leaves roles, payments, and edge cases open, and every firm fills the gaps differently. The more specific your brief, the closer the quotes will be, and the easier they are to compare.
Is a no-code tool cheaper than custom development?
Often, yes, at the start. No-code tools suit simple internal tools and early tests. They become expensive when you need behavior the tool does not offer or when usage fees grow. We compare the two in no-code automation vs custom code.
Should I ask for a fixed price or pay hourly?
A fixed price suits a well-defined scope. Hourly or staged billing suits work where the requirements will be discovered along the way. Both are fair when the scope is honest. Our post on fixed price vs hourly development explains the trade-offs.
Does adding AI features raise the cost?
It adds a usage fee per request and extra work to check the output, since AI answers can be wrong. A narrow AI feature with a human reviewing results is a modest addition. An app built around unreviewed AI output is a larger, riskier project.
Does the choice of technology change the price much?
Less than people expect. Scope moves the price far more than the framework does. A developer working in tools they know well will be faster than one learning yours.
If you want a real number, send us a few sentences about what the app must do and pick a budget range. We will tell you what fits inside it.