How Much Does It Cost to Build an MVP or Web App in 2026?

Every founder and product lead asks the same first question, and most vendors dodge it. Search for the answer and you will find ranges that run from a few thousand dollars to well into six figures, usually written by someone selling the cheap end or the expensive end. Both can be “true,” because they describe different products.

This guide explains what actually moves the price of an MVP or custom web app, how to estimate it yourself before you talk to anyone, what a fixed-scope quote should and should not include, and where teams quietly overspend. It is written from a New York product engineering studio’s seat, so it is honest about what we quote and why we quote it the way we do.

Why the honest answer is “it depends” (and how to make that useful)

Software cost is mostly people over time. A rough model that holds up in practice:

cost ≈ (people on the team) × (weeks) × (their blended rate) + (everything that isn’t engineering)

Two of those three inputs are things you control through scope. The rate is something the market sets and you compare across vendors. So the useful question is not “what does an MVP cost?” but “which slice of the product am I buying, and how many person-weeks is that slice?”

For reference, Westama’s typical product engineering engagement is a 2–4 person pod working for 8–16 weeks, and most of that work starts in the mid five figures. Immersive 3D and native mobile sit higher. We say this publicly because a buyer who hears “mid five figures” and “not a weekend project” can decide quickly whether we are even the right fit. That is a floor for the kind of work we do, not a promise about your project. The real number comes after scoping.

What drives the cost of a web app

Roughly in order of how much they move the number:

1. How many distinct workflows you are building

A “workflow” is a thing a user can finish: sign up, create a project, invite a teammate, pay, export a report. Cost scales with the number of workflows far more than with how polished any one screen is. A product with two workflows and one with ten are not the same project, even if both are called an MVP.

2. Accounts, roles, and billing

Authentication looks cheap until you add teams, roles, invitations, password resets, single sign-on requests, and an admin who can see everything. Subscription billing adds plans, trials, failed payments, invoices, and tax edge cases. If you sell to businesses, assume this layer is a real chunk of the work, not an afterthought.

3. Integrations

Each system your product has to talk to (payments, CRM, helpdesk, accounting, identity, a partner’s API) costs build time, testing time, and ongoing maintenance when the other side changes. Integrations with good documentation are quick. Integrations with poor documentation, rate limits, or “call our account manager” access are where timelines slip.

4. Data model and migration

A new product on an empty database is the cheap case. If you are replacing a spreadsheet, a legacy tool, or an undocumented system, someone has to understand the existing data, clean it, and move it. This is often the least visible and most underestimated line item.

5. Design depth

A clean, conventional interface built from a solid component set is faster than a bespoke interaction system. Custom motion and 3D can be the right call when they help someone understand or configure something, but they are a deliberate spend. We covered when that spend pays off in Three.js & WebGL — When It Pays.

6. Quality bar and risk

Does this system handle money, personal data, or operations a business cannot afford to have down? Then you are paying for tests, monitoring, access control, backups, and a rollback plan. Cutting those is how a cheap build becomes an expensive one six months later.

7. Platform choice

Not everything needs custom code. A storefront that fits Shopify’s standard toolkit is faster and cheaper on Shopify. A content site your team edits weekly may belong on WordPress or Webflow. A custom build only earns its cost when your logic does not fit the platform. Anyone who recommends custom code before asking what you actually sell is guessing.

A worked example (hypothetical)

Consider a typical SaaS team that wants a client portal for a services business. The first draft of the wishlist has: accounts and roles, project dashboards, file sharing, messaging, invoicing, a reporting module, a mobile app, and integrations with three tools.

Run the person-weeks logic on it:

• Must exist on day one: accounts and roles, one dashboard, file sharing, one integration the business cannot operate without.
• Can be a phase two: invoicing (use the existing accounting tool for now), reporting (export a CSV), messaging (keep using email), the second and third integrations.
• Probably never: a native mobile app, until usage shows people want one. A responsive web app covers most of the need.

The first slice might be a single pod over a single phase. The full wishlist could be several times that. Nothing about the product vision changed. We changed the order. That reframing, not a discount, is how most teams get to a budget they can approve.

This example is illustrative, not a client result. Your numbers will be different, which is exactly why a written scope comes before a price.

What an MVP actually is (and isn’t)

An MVP is the smallest thing that lets you learn whether real users will do the core job. It is not a worse version of the final product, and it is not a prototype that falls over at the first edge case.

Good MVP scope has three properties:

1. One core job a user can complete end to end.
2. Real authentication and data handling, because rebuilding those later is expensive.
3. A measurement plan, so you know what “it worked” looks like before launch.

A thin demo with no backend is cheaper, but it answers a different question (“does this look convincing?”). If your goal is to learn from paying or pilot users, you need the real thing, scoped small. If you only need to show investors a direction, say so honestly, and buy the right level of fidelity.

How a fixed-scope quote works

Our process is deliberately boring, because boring is predictable:

1. Scoping call, 30–45 minutes, free.
2. Written proposal with fixed scope, fixed quote, and a start date, usually within 2–3 business days.
3. Kickoff, then weekly builds of working software.
4. Ship and hand off with documentation and a defined support window.

Fixed-scope projects are billed in milestones tied to delivered work. If a project is cancelled mid-build, you keep everything delivered through the last completed milestone and owe only for that work. A scope change is quoted separately, in writing, before it starts, so it never quietly expands the current milestone’s price or timeline.

A quote worth trusting states what is in, what is out, what you must provide (access, content, decisions), and what happens if scope changes. If a number arrives without those four, it is an opinion, not a quote.

If you are weighing vendors against each other, How to Choose a Software Development Company walks through how to compare proposals line by line.

Where teams quietly overspend

• Building for the roadmap instead of the first release. Every “while we’re at it” feature has a price and a maintenance tail.
• Skipping scoping to “save time.” Vague scope is how a fixed number becomes an open-ended burn.
• Custom everything. Authentication, email, payments, and analytics are solved problems. Use well-maintained building blocks and spend your budget on what is unique to your product.
• Late decisions. A client who can approve scope changes without a committee finishes faster than one who needs three meetings per question. Decision speed is a cost lever, and it is entirely yours.
• Ignoring running costs. Hosting, third-party APIs, monitoring, and any AI usage are ongoing line items after launch. Ask for an estimate of the monthly run cost, not only the build cost.
• No handoff plan. If the code, cloud accounts, and documentation are not yours at the end, the true cost includes the next migration.

How to reduce cost without cutting quality

1. Cut workflows, not quality. Remove features before you remove tests, security, or monitoring.
2. Phase by learning. Ship the first slice, watch real usage, then decide what phase two should be.
3. Reuse platforms where they fit. Standard tooling is faster and cheaper whenever your requirements fit it.
4. Prepare your inputs. Brand assets, copy, existing system access, and a named decision-maker at kickoff save more than most negotiations.
5. Ask for the tradeoff options. When something slips, a good partner gives you extend, cut scope, or add capacity, with consequences, not a silent delay.

A pre-call checklist you can fill in today

Before you contact any studio, write down:

1. The one job the product must let a user finish.
2. Who the first ten users are and how you will reach them.
3. Systems it must integrate with, and who owns the credentials.
4. Where the data lives today.
5. What happens if it is down for an hour.
6. Your decision date and the person who can approve scope.
7. A budget range you can say out loud, even a wide one.

Even a rough budget range helps. Studios can then tell you honestly whether the scope fits, or what fits the budget, instead of quoting into the dark.

Bottom line

The cost of an MVP or web app is the cost of a scoped slice of work: people, weeks, and risk. Shrink the slice and the price drops. Skip the quality bar and the price drops now and returns later with interest. The cheapest way to find the real number is a clear scope and a written, fixed quote.

If you are building a custom web product or SaaS surface and want a number you can plan around, we are happy to talk through scope.

---

Next step

Start with the service that matches the work, then talk scope.

• Web & Product Engineering: /services/web-product-engineering
• How we work, step by step: /process
• Related reading: What a Product Engineering Studio Actually Does
• Start a project: /contact