How much does a web application cost?

1. Website vs. web application: the key distinction

Websites display pages, text, images and forms. Apps act on data: users log in, create and update records, confirm bookings, generate invoices, update inventory or trigger approval emails. Both run in a browser, but they're built very differently.

The distinction has nothing to do with how it looks or which technology stack is underneath. It's about whether the software reads data or creates and transforms it. And that distinction is what drives the cost difference.

A few examples of where the line falls:

• Website: a service business homepage with a contact form, service pages, and a gallery. Users browse and send a message. Nothing gets stored or acted on beyond the email.
• Web application: a client portal where the same business's customers log in, view their project status, upload files, and see invoices. Data is created, stored, and displayed per user.
• Website: a restaurant site with a menu page, hours, and a link to a third-party reservation tool. Static content only.
• Web application: that same restaurant's internal operations tool — staff scheduling, supply orders, table management. Multiple user roles, business rules, and data persistence.

The reason this distinction matters for cost is that authentication, database design, business logic, and state management are each significant engineering problems. A website has none of them. A web application has all of them, and every feature that builds on top of that foundation adds more. Web app development →

2. Cost ranges by complexity tier

These ranges are useful budgets before discovery. Your number is fixed once the scope is written down.

Ranges assume a written specification. A vague request like "Airbnb for boats" leaves too much open, so a quote either pads for contingency or ends in scope disputes. Defined workflows, roles and data models make the estimate accurate and protect both sides.

3. What moves the price

Each range starts at the base build. These add-ons move a quote toward the top:

Beyond the add-ons, three things push a quote up: the number of user types (each role needs its own permissions and screens), how many outside systems the app talks to, and how messy the data you're bringing in is. Fewer roles, fewer connections and clean data keep you near the bottom of the range.

4. The six main cost drivers

Web app cost doesn't come from nowhere. Every major line item on a development estimate maps back to one of these six engineering problems. Understanding them helps you figure out which features are worth the cost and where cutting scope saves money vs. where cutting scope creates bigger problems later.

Authentication and user management

Secure login comes before any business logic: hashed passwords, sessions, login rate limits, safe password resets, CSRF protection and optional two-factor sign-in. Each role (admin, staff, customer, read-only) also needs its own permissions on every feature. Mistakes here are costly.

Database design

The records, how they relate and how they'll be searched get planned before building. A good schema speeds up development. A bad one compounds: slow queries, painful migrations, reports you can't run and records that drift out of sync. Fixing it later is expensive.

Business logic and workflow encoding

Business rules require tested code, including edge cases: approvals, calculations, conditional access, triggers and order transitions from pending to confirmed, shipped and delivered. Similar interfaces can conceal very different workflow complexity, driving estimate variation.

Third-party integrations

Every integration adds code, failure handling and an ongoing dependency. Payments through Stripe or Square have to handle failed charges, renewals and refunds. CRM, shipping, calendar, maps and accounting connections also need tested responses for when the other service is down or changes its API.

Admin dashboard and internal tools

The admin side can take as much work as the customer side: search, filters, bulk actions, audit logs, account management and settings. Cutting it often means paying a developer to run database queries for routine tasks within six months. A good admin panel pays for itself in support time saved.

Real-time and asynchronous features

Live notifications, chat and collaboration, scheduled jobs and long exports need extra infrastructure: push messaging, background queues and scheduled runners. Each one adds failure points, scaling and upkeep. "Live updates" is a real engineering cost.

5. Discovery, scoping, and why it changes the number

Vague requirements cause most budget surprises: developers either price ambiguity through contingency or interpret narrowly and discover added scope mid-build. The result is high quotes or overruns.

Discovery documents how your users work today, what needs to change, who has which role, what data gets stored and pulled, which systems it connects to, and what counts as done for version one. It ends in a specification you both approve before pricing.

Specifics can change a feature's cost by 10x. "Users can message each other" could mean a simple two-user contact form (a few hours), threaded messaging with read receipts (a few weeks), or real-time chat with attachments and history search (months). Discovery is part of the quote; larger builds may scope it as a paid first phase.

Get the quote after discovery. A price given on the spot for a vague scope either pads heavily, which prices out simple projects, or assumes the narrowest reading and leads to change orders. A developer who asks hard questions before pricing is doing the job right.

Want a budget figure before that conversation? Cost estimator →

6. Build timelines by project type

Three developers may build faster than one without costing less, because coordination and reviews take time too. These timelines assume a clear spec and a solo developer or small team.

• Simple internal tool (6–10 weeks). A focused single-workflow app with one or two user roles, a database backend, and a basic admin view. The most predictable timeline in this category because scope is usually well-defined and there are few integration dependencies.
• Multi-role portals (3–6 months). Accounts, core workflows, email, an admin panel and integrations bring more decisions and edge cases than an internal tool. How often requirements change decides where in that range you land.
• Complex multi-role application (6–12 months or more). Multiple user roles with distinct workflows, real-time features or background jobs, several integrations, and heavier reporting. At this complexity level, the timeline is heavily dependent on whether decisions get made quickly and how much stakeholder review the build goes through. Waiting two weeks for a product question is a two-week delay.

Define version one and hold that scope. New features belong in the next version. Mid-build additions must fit an existing architecture and often force refactoring. That delay reflects missing early requirements, not incompetence.

7. Ongoing costs after launch

The build cost is the biggest single expense, but it's not the last one. A web application has operational costs that start the day it goes live and don't stop. Budget for these before you start the build, not as a surprise after launch.

• Hosting. If your app is on a managed plan, hosting is billed separately from the build: Core at $60/mo (SSL, nightly backups, uptime monitoring, server patches), Care at $100/mo (adds an hour of content edits a month and application-level security patching), or Priority at $180/mo (more edit hours, same-day critical response, a test environment).
• Changes after launch. Bug fixes, new features and other changes are billed at $100/hr as needed. Content edits fit inside Care; new features are quoted separately.
• Email delivery. Confirmations, password resets and notifications go through a dedicated email service (Resend, Postmark, SendGrid, Mailgun) so they don't land in spam. It's priced by volume and billed by the provider.
• Third-party fees. Stripe charges 2.9% + $0.30 per card payment¹. Maps, SMS and background checks charge per use beyond their free tiers. Estimate these before launch.
• Domain. Your domain renewal is billed by your registrar.

Your fixed monthly cost is the hosting plan. Everything else depends on usage and how often you change the app. That's often less than per-seat SaaS once your team grows.

8. Build vs. buy: when custom makes sense

Building a custom web app is not always the right answer. There are solid off-the-shelf SaaS products for most common workflows, and paying $49/month for one of them is often smarter than spending $30,000 to replicate it. The key is figuring out which category you're in.

When SaaS is the right answer:

• Buy when workflows fit without heavy customization. Jobber field scheduling, Basecamp projects and Chargebee subscriptions serve common operations well; don't reshape your business around software limitations.
• The per-seat or per-usage cost is manageable at your current and projected team or customer size. Run the five-year math at your expected headcount alongside the first-month cost at launch. A $25/seat/month tool with 10 users is $3,000/year; at 200 users that same tool is $60,000/year — a number that changes the calculus.
• Buy when your compliance rules (HIPAA, privilege, SOC 2, data residency) allow a vendor to store the data.
• The feature gaps are small enough to work around, not large enough to break your workflow. A feature gap you solve with a five-minute manual step is a feature gap. A gap that requires re-entering data from one system into another every day, or that prevents you from automating a core business process, is a signal to look elsewhere.

When custom wins:

• Your workflow is specific enough that you're duct-taping four or five SaaS tools together with Zapier to approximate it, and the whole thing breaks whenever any one of those tools changes its API, pricing, or feature set.
• Per-seat fees compound past the build cost at scale. A SaaS tool at $50/user/month with 100 users is $60,000/year. A custom build at $40,000 on Priority hosting ($2,160/year) breaks even in about 9 months, and you own it permanently.
• Your data model is specific enough that you're constantly mapping your entities into the SaaS product's field structure. If you spend more than a few hours configuring a CRM, an ERP, or a project management tool before it resembles your actual business, that's friction that will never go away, because the product's data model was designed for someone else.
• Competitive differentiation depends on the workflow itself. If the way your business operates is the thing you're selling — a proprietary underwriting model, a specialized dispatch algorithm, a unique client experience — you cannot build that moat on a platform that also sells it to your competitors.
• You've already been through the SaaS cycle. You bought the product, configured it, trained the team, and discovered that the 20% of your workflow it doesn't support is eating 40% of your team's time in workarounds. That's usually the clearest signal that custom is the right answer, because you now know exactly what to build.

9. Build vs. subscribe: app builders by the numbers

If your app could be built on a no-code platform, compare five years of that subscription against a simple custom app ($6,000–$11,000) plus Core hosting at $60/mo. Here's that math for a 10-person team; change the team size and years to fit yours.

Over five years with 10 users, a custom app on Core hosting comes to $9,600–$14,600. Airtable Business comes to $27,000², so a custom build costs less. Bubble Growth (web) comes to $7,140³, so the subscription costs less. Bubble Team (web) comes to $20,940³, so a custom build costs less. Airtable charges per editor seat, so its cost grows with your team; Bubble prices per app, so the number of users doesn't change its bill, but heavier usage can push you onto a higher plan or paid workload add-ons. Where the subscription costs less, the reasons to build are fit, owning your data and code, and having one system instead of several.

The full breakdowns, including when each platform is the right call: Airtable vs. a custom app → and Bubble vs. a custom app →

10. Key takeaways

• A web application has business logic that acts on data: users log in, records get created and modified, actions trigger concrete outcomes. A website just displays information. That distinction is what drives the cost difference.
• Simple internal tools run $6,000–$11,000. Basic client portals run $5,500–$10,000, and full multi-role client/partner portals run $16,000–$30,000. Complex multi-role applications run $40,000–$65,000. All of these assume a clear, written scope.
• The six main cost drivers are: authentication and user management, database design, business logic, third-party integrations, admin dashboards, and real-time or async features. Understanding which of these your app needs tells you a lot about where your budget is going.
• Scope ambiguity is the single biggest source of budget overruns. A proper discovery process (documenting workflows, user roles, data models, and integrations before any code is written) pays for itself in avoided rework.
• After launch, budget for hosting (Core $60/mo, Care $100/mo or Priority $180/mo), changes at $100/hr as needed, and third-party usage like email and payment fees.
• SaaS wins when your workflow matches the product and the per-seat economics work at your scale. Custom wins when the workflow is specific, the per-seat fees compound past the build cost, or data ownership and compliance requirements rule out third-party storage.
• Ranges are published; your number is fixed after discovery. Any developer willing to quote a fixed price against a vague spec is either padding heavily or planning to dispute scope mid-build.

11. Common questions

See all FAQs →