What Building an MVP Actually Costs

Every founder asks the same question in the first ten minutes of a call: "What's this going to cost?"

And almost every studio gives the same non-answer: "It depends on scope." Which is true, and also useless. It's the contractor who won't quote until they've seen your house, except the house is imaginary and you're the one who has to describe it.

So let me do the thing our industry mostly refuses to do and give you actual numbers, plus the reasoning behind them, so you can pressure-test any quote you get, from us or from anyone else.

The ranges, up front

These are 2026 numbers for a senior team building a production-quality product, not a clickable prototype. Design and engineering included. No offshore-junior arbitrage, no "we'll fix it in phase two."

• Thin wedge: $25k–$50k, 4–8 weeks. One core flow, done properly. Auth, one primary object, one primary action, a way to see results. This is what you build when the question is "will anyone use this at all?"
• Fundable MVP: $50k–$120k, 8–16 weeks. Several connected flows, real data model, payments or integrations, an admin surface, and enough polish that a demo doesn't need apologies. This is the most common shape.
• Complex or regulated V1: $120k–$300k+, 4–8 months. Anything with compliance exposure, multi-tenant permissioning, real-time infrastructure, or a machine learning component that has to actually work rather than demo well.

If someone quotes you $15k for the middle bucket, they're either misunderstanding the scope or planning to hand it to people who will. Both cost you the same in the end, just later and with worse timing.

What actually moves the number

Here's the part rate cards don't tell you. Three variables account for most of the variance between a $60k build and a $180k one, and only one of them is about features.

1. How many decisions are still open

This is the big one, and almost nobody prices it explicitly.

A project where the founder knows exactly who the user is, what the one critical action is, and what "working" means costs dramatically less than one where those things get discovered mid-build. Not because the code is different, but because the second project builds three versions of everything.

I've watched two teams with nearly identical feature lists land forty percent apart on cost, entirely because one of them had done the thinking and the other was doing it on our clock. Ambiguity is the most expensive line item in software, and it never appears on the invoice under its own name.

If you want to lower your quote, the highest-leverage move is not cutting features. It's arriving with fewer open questions.

2. Integrations you don't control

Your own code is predictable. Someone else's API is not.

Stripe is fine. Auth providers are fine. The moment you touch a legacy insurance system, a bank's file-drop endpoint, a hospital's HL7 interface, or any enterprise SaaS with a "contact sales for API access" page, the estimate stops being an estimate. Sandbox environments don't match production. Documentation is three versions stale. The support contact takes eleven days to answer.

Budget integrations at two to three times what the happy path suggests, or scope them out of V1 entirely and fake them with a human in the loop. A founder doing manual data entry for the first fifty customers is not technical debt. It's research.

3. Whether design and engineering are the same team

This is the one we're obviously biased about, so treat it accordingly, but the mechanism is real and easy to verify yourself.

When design and build are separate vendors, or separate teams inside one vendor, every screen crosses a boundary. Boundaries produce artifacts: specs, annotations, handoff meetings, clarification threads, and a QA pass whose entire purpose is catching the difference between what was drawn and what was built. None of that work makes the product better. All of it gets billed.

The overhead is typically fifteen to thirty percent of the total, and it's not a line you can negotiate away; it's structural. The only way to remove it is to remove the boundary.

The costs nobody quotes

Four things reliably fall outside the proposal and inside your bank account.

Infrastructure and services. Hosting, database, email delivery, error tracking, analytics, file storage, and whatever AI provider you've built on. Budget $200–$800 a month at MVP scale. It goes up faster than you expect the moment you have real users, and AI inference in particular can go up a lot faster than that.

Design and brand assets. If you don't have a logo, a type system, and a color palette, someone has to make them. That's a real few-week piece of work, not something that happens between sprints.

The gap between "done" and "launched." App store review, DNS, legal pages, a support inbox, an onboarding email, someone to answer the first bug report at 11pm. Reliably two to four weeks that no proposal includes.

Iteration after launch. This is the one that hurts. Teams spend their entire budget getting to launch, then discover (correctly, usefully) that half their assumptions were wrong, and have nothing left to act on it. Hold back twenty to thirty percent. The learning is the point of shipping; you need capital to act on it.

Fixed price, time and materials, or retainer

Three models, and the right one depends almost entirely on how open your decisions still are.

Fixed price works when scope is genuinely locked. It transfers risk to the studio, and they price that risk in. Expect a fifteen to twenty-five percent premium, plus a change-request process that turns every mid-flight discovery into a negotiation. It's the wrong instrument for early product work, because early product work is defined by mid-flight discovery.

Time and materials is honest and flexible and requires trust, because the client carries the risk. It works when you have enough judgment to tell whether progress is real, or a studio with a track record you can verify.

Retainer, a fixed monthly cost for a committed team, is what most good early-stage work looks like in practice. You get predictable burn, the studio gets predictable capacity, and scope stays a conversation instead of a contract clause. The failure mode is paying for a team that isn't shipping, so tie it to visible weekly output, not hours logged.

Our own default is a retainer with a scoped first milestone, precisely because we expect the plan to change once real users touch the thing. A contract that punishes you for learning is a badly designed contract.

How to make a quote comparable

When you get three proposals back, they will be impossible to compare, because each one has silently made different assumptions. Force them onto the same footing:

• Ask what's excluded, not what's included. The inclusions list is marketing. The exclusions list is the truth.
• Ask who writes the code. Names and seniority. "A senior-led team" often means one senior reviewing four juniors' pull requests on Fridays.
• Ask what happens when an estimate is wrong. Not if; every estimate is wrong. Who absorbs it, and how do you find out?
• Ask for the smallest version they'd ship. A studio that can't describe a cheaper version of your product than the one you asked for isn't thinking about your product. They're transcribing your spec.
• Ask what you own at the end. Repository, infrastructure accounts, design files, domain. If any of those live in the vendor's account, you have a hostage situation waiting to happen.

The number that actually matters

Cost is the wrong headline metric. The one to optimize is money spent before you learn something true.

A $40k build that puts a real product in front of real users in eight weeks is better than a $40k build that takes six months, and it is dramatically better than a $150k build that launches complete and wrong. The second one didn't just cost more; it cost more and delayed the only feedback that could have corrected it.

Every additional week before contact with users is a week you're paying to be confident instead of paying to be correct. Price your MVP accordingly: not by what it contains, but by how fast it tells you the truth.

If you want a real number for your specific product, tell us what you're building. We'll give you a range and the reasoning, whether or not you end up working with us.