How much does a web app cost to build in 2026? Cost drivers, running costs and how to read a quote

Web app development cost is hard to pin down because "web app" covers everything from a booking tool with one login to a platform with teams, billing and an AI assistant. Two quotes for what sounds like the same idea can differ by several times, and both can be honest, because each developer pictured a different product.

This guide is for founders and business owners planning a web app: a customer portal, an internal tool, a SaaS product or a marketplace. It explains what moves the price, why the first version should be small, what the app costs to run after launch, and how to spot a quote that will cost you more later. It ends with my own published starting prices and what I quote from a brief.

If you are building a phone app instead, my guide to what an app costs to build covers the mobile side. This one is about apps that run in the browser.

Website or web app: where the price jumps

A website is pages. People read, browse and maybe fill in a form. A web app is a product people sign in to and use: they create things, change things and see their own data. That shift brings three costs a website does not have:

• Accounts. Sign-up, sign-in, password resets, email verification and sessions that expire safely.
• Data. A database designed for your records, an API in front of it, backups, and rules about who can read and change what.
• States. Every screen has an empty state, a loading state, an error state and a full one, and each needs designing and testing.

That is why my website plans jump from content sites to the Advanced plan the moment sign-in and a database appear.

What drives web app development cost

These are the decisions that move a quote most, roughly in order.

Accounts and roles

One kind of user is the cheapest case. Each extra role, such as admin, manager, staff or client, adds screens, permission checks and tests to prove that one customer can never see another's data. If several companies share the app, each with its own users and data, that is a multi-tenant design, and it should be decided before the first table is created, not bolted on later.

Dashboards and admin screens

Most web apps need two products: the one customers use and the one you use to run it. The admin side, with user management, moderation, refunds and settings, is the part buyers forget to price. FeedSeek is an example: behind the app sits a backend with accounts, listings and reservations, and an admin console to run it. Reporting dashboards add their own work, because every chart is a query that has to stay fast as data grows.

Integrations

Every outside system, whether a CRM, accounting software, a calendar, email or a marketplace, brings its own authentication, rate limits and failure modes. Reading data once is simple. Keeping two systems in agreement means webhooks, retries and a check that nothing was missed.

Data you already have

Importing customer lists, product catalogues or years of records from spreadsheets and old systems is often the most underestimated task in the project. Old data is messy, and someone has to decide what to keep, clean and map.

Payments

A one-off checkout through a provider like Stripe is modest work. Subscriptions are not: plans, trials, upgrades, failed payments, invoices, refunds and tax all need handling. Providers also take a fee on every payment; Stripe's standard US rate is 2.9% plus 30 cents per successful domestic card charge, with no monthly fee. Plan that into your margins as well as the build.

AI features

An AI feature is two costs: building it well, with fallbacks for when the model is wrong and limits on what it can do, and paying for every request after launch. I break down both in what an AI agent costs to build and run.

Start with an MVP, not the whole roadmap

The surest way to lower web app development cost is to build less first. Pick the one job the app must do, build the shortest path through it end to end, and release it to real users. My MVP guide goes through how to choose.

For a web app, that usually means:

• One role first. Add managers and teams when people ask.
• Manual admin to begin with. An admin can approve accounts or issue refunds by hand until volume justifies automating it.
• Managed services for sign-in, email delivery and file storage, rather than building your own.
• One integration, the one the core job cannot work without.

What you should not cut is whatever makes the app trustworthy: permissions that keep data private, backups you have tested, and correct numbers wherever money is involved.

Running costs after launch

The build is a one-off. These continue every month:

• Hosting and database, usually small at launch and growing with users and data.
• Third-party services: email delivery, file storage, error monitoring, maps, SMS.
• Usage-based charges, above all AI model calls, which grow with every user.
• Payment fees on every transaction.
• Maintenance. Frameworks and libraries release security fixes and new versions all the time. Node.js, which runs many web app back ends, gives a long-term-support release about 30 months of critical fixes, and the Node.js release page already lists version 20 as end-of-life. An app nobody updates becomes an app with known security holes.

Ask every developer who quotes you to list these for your app. A good one names the categories without being asked, and puts every account in your name.

AI-built prototypes: what they change and what they don't

AI coding tools and app builders have made a clickable prototype cheap and fast, and that is useful: it is a better brief than any document. Developers use these tools too. In Stack Overflow's 2025 Developer Survey, 84% of respondents said they use or plan to use AI tools in their work. The same survey found the most common frustration, named by 66%, was AI answers that are "almost right, but not quite".

That gap is where the cost of a production web app lives: permissions that hold under every edge case, data that stays consistent, payments that reconcile, and code someone can maintain. A prototype shows what the app should do. Production is making sure it always does it.

My published website plans, and what I quote from a brief

These are my website plans, all starting prices in US dollars:

Plan	Starts at	What it covers
MVP	$1,000	Up to 5 pages or one long landing page, responsive, contact form, search basics
Flexible	$2,500	Up to 12 pages or a blog, content you update yourself, analytics, newsletter or booking tools connected
Advanced	$5,000	Sign-in and user accounts, dashboard and admin screens, a database and API built for it, payments or AI features where the product needs them

The Advanced plan is the starting point for a web app. Anything beyond its scope, such as several roles, multi-tenant accounts, subscriptions or heavy integrations, is quoted from a brief. Every project gets a fixed quote after that brief, before any work starts, with payment in milestones that are each something you can open and try. You own the code and the accounts, and you get handover notes. The page on building a website or web app with me explains the process.

Red flags in a web app quote

• An hourly estimate with no written scope. You cannot compare it with anything.
• No admin side mentioned. Someone will need to run the app.
• Hosting, domains and services in the developer's name. They should be yours.
• No running costs listed. They exist whether the quote mentions them or not.
• One payment at the end, or one big reveal. You should see working screens early.
• AI features with no plan for usage costs or for what happens when the model is wrong.
• No word on backups, data import or security.
• A price far below the others. Line up the scopes; the cheapest quote usually leaves the most out.

How to brief for an accurate quote

A good brief is a page, not a specification. Include:

1. What the app is for, in one sentence.
2. Who uses it, and what each kind of user needs to do.
3. The core flow, step by step, from sign-up to the job done.
4. What already exists: data, systems, designs, a prototype.
5. Integrations, payments and AI the first version cannot do without.
6. When you need it working, and why.

FAQ

Is a web app cheaper to build than a mobile app?

Often, for the same features. A web app runs from one codebase in every browser, needs no app store review and updates for everyone the moment you deploy. A mobile app suits products that rely on the camera, location, notifications or offline use. On my published plans, a web app with sign-in, admin screens and its own database starts at $5,000, and a mobile app with accounts, a backend and admin screens at $6,000.

What does a web app cost to run each month?

It depends on users, data and services, so be wary of any single figure. The usual items are hosting and a database, email delivery, file storage, error monitoring, payment fees on every transaction and, if the app uses AI, a charge for every model request. Add maintenance for security updates and new framework versions. Ask your developer to list each item for your app before the build starts.

Should I pay a fixed price or by the hour for a web app?

For a first version with a clear brief, a fixed price paid in milestones protects you best: you know the total, and each payment matches something you can open and try. Hourly billing suits work whose scope keeps changing, but it needs close tracking. I quote every project as a fixed price after a short brief, before any work starts.

If you are planning a web app, send me a short brief: what it is for, who uses it, what already exists and when you need it working. You can start a brief for the Advanced website plan, read about my full-stack web development work, or see how to keep the first version small in the MVP development guide.