How much does it actually cost to build an MVP?
A minimum viable product costs somewhere between nothing and several hundred thousand, and that range is not a dodge — it is the actual answer. The number depends almost entirely on two decisions: how many features you insist on shipping in version one, and who writes the code. Everything else is rounding.
The calculator above makes those two variables concrete. Tick the features you think you need, choose who is building, and watch the range move. Most founders are surprised by how much a single feature — payments, chat, AI — moves the number, and that surprise is the useful part.
What actually drives the cost
Feature count, not complexity
Founders tend to estimate by how hard a feature sounds. Real cost tracks how many distinct features you ship, because each one carries the same hidden overhead: a data model, a screen, validation, error states, tests, and a place in the navigation. A feature that takes two days to build takes another two to finish properly. Ten features is not ten units of work — it is ten units plus the cost of everything having to work together.
This is why cutting scope is the single most effective lever you have. Removing a feature removes its entire cost, including the invisible half.
Who writes the code
The same MVP built by four different teams produces four very different invoices:
- You or a technical co-founder. No cash cost, but a real one: the weeks you spend building are weeks you are not selling, and the equity you trade is permanent.
- Freelancers. Usually the best value for a first version. You manage the work, which is a real job.
- A local agency. The highest rate, and you are paying for process — project management, QA, accountability, someone to call. Worth it when the cost of getting it wrong is high.
- An offshore agency. A lower rate, offset by time zones and specification overhead. Works well when your requirements are genuinely settled; badly when they are not.
Design depth
An off-the-shelf UI kit costs almost nothing and looks like an off-the-shelf UI kit — which, for an MVP proving whether anyone wants the thing, is usually fine. Bespoke design adds meaningfully to the bill and pays off when the product's appeal is the experience. Between those sits custom-but-conventional work, which is where most funded MVPs land.
Platform
Web is the cheapest place to start and the fastest to change: one codebase, no app-store review between you and a fix. Two native apps roughly double the build. Cross-platform frameworks land in between and are the right answer for most products that genuinely need to be on a phone.
The features that cost more than founders expect
- Payments. Taking a card is the easy part. Refunds, failed charges, proration, dunning, tax, and invoices are the rest — and customers notice every one of them.
- Messaging. Real-time delivery, unread state, notifications, and moderation. Chat is rarely a small feature.
- AI features. The API call is trivial. Prompt iteration, handling wrong answers, rate limits, and per-request costs that scale with usage are not.
- Admin dashboards. Easy to underestimate because nobody demos them, and impossible to operate without.
- Third-party integrations. Each one is a separate authentication flow, a separate set of failure modes, and a separate thing that breaks when the other company changes their API.
How to bring the number down
- Write down the one thing your product must prove. Then cut every feature that does not help prove it. This is the whole discipline.
- Buy, don't build, anything that is not your product. Authentication, payments, email, analytics, error tracking. None of these are why anyone will pay you.
- Ship to a waiting list before you ship to the public. A smaller, friendlier first audience means you can skip a great deal of polish and edge-case handling in v1.
- Do the manual version first. If a human can do the job behind the scenes for your first fifty users, do that and build the automation once you know it is worth automating.
- Set a budget before you get quotes, not after. Scope expands to fill whatever number you first say out loud.
What to do with the estimate
Treat the range as a decision-making tool rather than a budget. If the number is comfortably affordable, stop planning and start building. If it is roughly double what you can spend, the answer is almost never to find a cheaper builder — it is to cut the feature list until the number fits. And if it is ten times your budget, you are not describing an MVP; you are describing version three.
Once it is built, the next problem is that nobody knows it exists. That is what AlphaShot is for: list your product and put it in front of people already looking for something new.