A founder once asked me why two “simple” dashboards were $4,200 and $18,000. What a web app actually costs is almost never the screens; it is the scope behind them: feature count, auth, integrations, data complexity, and revision rounds.
What is included in a typical web app quote?
A web app quote is a fixed or phased price for software people log into and use, not a brochure site. At Subsecond Studio I price the work that ships: discovery, product structure, UI, front end, back end or BaaS setup, auth, data model, integrations, QA, and a defined round of revisions.
The low end of the band ($3,000–$6,000) usually means a narrow MVP: one primary user role, a handful of screens, email magic-link or a hosted auth product, and almost no third-party APIs. The high end ($20,000–$30,000+) usually means multi-role permissions, payments or CRM hooks, non-trivial data, admin tools, and enough edge cases that you need real test time.
I treat “web app” as software with state: users, records, rules, and workflows. A marketing site with a form is not that. A client portal with roles, uploads, and status is. Pricing follows that difference, not the number of pretty mockups (see marketing site).
How much does a custom web app cost by scope?
Here is the range I see for small businesses and founders when the design is approved before build and the scope is written down. Numbers are USD project fees, not retainers, and they assume a clear brief (see clear brief).
| Scope band | Rough cost | Typical timeline | What you usually get |
|---|---|---|---|
| Lean MVP | $3,000–$7,000 | 3–6 weeks | 1 role, 4–8 screens, basic auth, simple CRUD, light styling |
| Standard product | $8,000–$16,000 | 6–12 weeks | 2–3 roles, dashboards, file or record workflows, 1–2 integrations |
| Complex / multi-system | $18,000–$30,000+ | 3–5 months | Permissions matrix, payments or CRM, reporting, admin, heavier QA |
A $3k job is not a “cheap version” of a $30k job. It is a smaller product. If you force the $30k list into a $5k budget, something gets cut: quality, timeline, or honesty about what ships.
On one founder build, the interface looked finished in week two. The quote doubled after we mapped roles, Stripe webhooks, and export rules. The UI was maybe 25% of the cost; the rest was behavior that only shows up when real data hits the app.
How does feature count change the price?
Feature count is the first lever. Each feature is not “one screen.” It is validation, empty states, errors, permissions, mobile layout, and often a place in the data model.
A rough rule I use in discovery: a tightly defined feature with one success path and one failure path costs far less than a feature that “should work like Salesforce for our niche.” When clients list 20 “must haves,” I force a top five for launch. That alone can drop a quote by 30–40% without killing the product.
Examples of features that look small and are not:
- Multi-step wizards with save-and-resume
- Bulk import from spreadsheets with validation
- Activity feeds and notifications
- Custom PDF export that must match brand layout
- Role-based views of the same record
If you can ship without those on day one, say so. Your first users will tell you which of them actually matter.
How much does authentication and user roles cost?
Auth is Y if X is “who can see and change what.” Simple auth is one account type, sign-in, password reset, and a protected area. Complex auth is invite flows, SSO, org workspaces, and a permission matrix.
Hosted auth (for example Clerk, Auth0, or Supabase Auth) keeps early cost down because you are not building password security from scratch. Budget roughly $800–$2,500 of project time for solid basic auth and onboarding. Multi-tenant orgs, invite links, and admin impersonation often add $2,000–$6,000 depending on edge cases.
Permissions multiply every feature. “Only managers approve invoices” means UI states, API checks, audit trails, and tests. I would rather price that explicitly than bury it in a vague “backend” line.
How do third-party integrations affect web app cost?
Integrations are where quotes jump. Connecting Stripe, HubSpot, QuickBooks, Google Calendar, or a legacy API means reading docs, handling webhooks, retries, partial failures, and sandbox testing. A clean, well-documented REST integration might land in the $1,000–$3,000 band. A brittle vendor API with poor docs and special auth can run $4,000–$10,000 for one connection.
Ask these questions before you add an integration to the must-have list:
- Does launch require live two-way sync, or is CSV enough for 90 days?
- Who owns the third-party account, API keys, and rate limits?
- What happens when the vendor is down or returns a partial payload?
- Is this integration for revenue, ops, or comfort?
If the answer to the last one is comfort, park it. You can always phase integrations after the core loop works. Performance and reliability still matter either way; web.dev is a solid free checklist for the front of the stack while you plan those hooks (see how to read a web performance report).
How does data complexity shape the number?
Data complexity is how many entities you track, how they relate, and what reporting you need. A single “Project” table with a status field is cheap. Projects with nested tasks, files, comments, time entries, and client-visible filters is a different product.
I price data work by:
- Number of core entities (users, orgs, records, events)
- Relationships (one-to-many is easy; many-to-many with history is not)
- Search and filters
- Imports and exports
- Soft deletes, audit logs, and retention rules
Founders often underestimate reporting. “Just a dashboard with last month’s numbers” can mean aggregation jobs, timezone rules, and edge cases around refunds or cancelled rows. If you only need three KPIs at launch, write those three down. Do not pay for a general analytics platform inside your MVP.
Usability research still applies when the product is custom software: people abandon tools that bury the next step. Teams like Nielsen Norman Group publish clear research on task flow and forms; I use that thinking when we cut screens, not only when we style them.
How many revision rounds should you plan for?
Revision rounds are a cost control tool. Unlimited revisions sound friendly and usually produce thrash. I prefer a written package: one discovery pass, one design approval, then one or two structured revision rounds in build for UI polish and bugfix, with out-of-scope changes logged as change orders.
What inflates revisions:
- Stakeholders who were not in the brief suddenly join mid-build
- Brand assets that arrive after UI is built
- “Can we also…” items that should have been a phase two list
- Redesigning flows after engineering has modeled the data
A clean process saves money. Approve wire structure before visual polish. Approve design before paying for production code. When a change alters data model or permissions, treat it as scope, not a free tweak. That habit alone keeps many projects inside a 10–15% contingency instead of a 50% overrun.
What should you cut first if the quote is too high?
If a quote lands above budget, cut in this order:
- Nice-to-have integrations (replace with CSV or manual ops for v1)
- Secondary roles and admin power tools (founders can use a simple admin first)
- Custom reporting (export to Sheets until patterns are clear)
- Polish that does not change task completion (micro-animations, extra empty states)
- Multi-language, multi-currency, or multi-region unless you already sell that way
Do not cut QA, security basics, backups, or clear error handling. Cheap failures cost more than a smaller feature list.
Also decide build vs buy. If an off-the-shelf tool covers 80% of the job, custom may be the wrong spend. Custom wins when your workflow is the product, when margins depend on a unique process, or when you need tight control over data and UX.
What does a healthy project timeline look like?
For a standard $8k–$16k product I usually see:
- Week 1–2: discovery, user stories, information architecture
- Week 2–4: design for primary flows, client approval
- Week 4–9: build (auth, data, UI, integrations)
- Week 9–11: QA, fixes, content and edge cases
- Week 11–12: launch checklist, handoff, training notes
Lean MVPs compress that. Multi-system work stretches it. Timeline and cost move together because calendar time is mostly people time plus waiting on access to APIs, copy, and decisions.
If you want fewer surprises, bring to the first call: who the users are, the three jobs the app must do on day one, which systems must connect, and a hard budget band. Vague ambition is the most expensive input I get.
FAQ
Is a $3,000 web app worth building?
Yes, when the problem is narrow and success is measurable. A $3k app that replaces a messy spreadsheet for ten users can pay for itself in a quarter. It is not worth it if you expect the same surface area as a funded SaaS product for that price.
Why do two similar-looking apps get very different quotes?
Because similarity is visual. In the actual product, auth rules, integrations, data shape, and revision policy decide the number. Two dashboards can share a layout and still differ by $10,000 in behavior and risk.
Should I use a no-code tool instead of custom code?
Use no-code when speed and internal ops matter more than unique UX or deep integration control. Use custom when the product is the business, when you need performance and ownership, or when you have already hit the ceiling of templates. Many teams start no-code, then rebuild the winning workflow in custom software once the process is proven.
If you are budgeting a build, write a one-page scope: users, top five features, must-have integrations, and what “done” means for launch. Bring that to a discovery call and ask for a phased quote with an explicit out-of-scope list. That document does more for cost control than any discount ever will.
Get your website designed before you pay. Subsecond Studio designs and builds websites, web apps, and AI tools, and you approve the design before any payment. Get an estimate