The honest answer to what an MVP costs is that it depends almost entirely on what you leave out, and that founders systematically leave out too little.
A first version exists to answer one question: will the people you think want this actually use it. Everything that does not help answer that question is expense deferred from later, brought forward to now, when you can least afford it and know least about what is needed.
What an MVP costs: three bands
| Band | What it is | Illustrative cost | Time |
|---|---|---|---|
| Prove the idea | One user type, one core flow, sign-in, and something that looks credible. Manual behind the scenes wherever a human can stand in for software. | $15,000 to $40,000 | 4 to 8 weeks |
| Usable product | Two or three user types, payments, the main flow properly built, basic admin so you are not editing the database by hand. | $40,000 to $100,000 | 2 to 4 months |
| Ready to sell to businesses | The above plus roles and permissions, an audit trail, integrations, the security posture a business buyer asks about, and reliability you can promise. | $100,000 to $250,000 and up | 4 to 8 months |
Illustrative ranges from the kind of work we quote, not a price list. If you are selling to consumers you may never need the third band. If you are selling to enterprises you will start there whether you like it or not, and pretending otherwise wastes the first six months.
What moves it
- How many user types. Each one is its own screens, permissions and edge cases. A marketplace has at least two and is therefore roughly two products.
- Whether money changes hands. Payments add compliance, refunds, disputes, failed cards and reconciliation. Always more than the integration itself.
- Whether it must be on a phone as an app. Web first is cheaper, faster and updates instantly. Do you need an app or a website is the decision, and for most first versions the answer is not yet.
- Regulation. Health, financial and children's data change the cost floor before a line is written.
- How much you have decided. Vague requirements are the most expensive input there is. Clarity is free and it is the largest discount available to you.
What to leave out
This is the list founders argue about, and each of these is genuinely deferrable.
- Your own login system. Use a provider. Nobody chose a product because of its password reset.
- An admin panel. For the first months you are the admin, and a database tool plus a spreadsheet is enough. Build it when someone else has to do the job.
- Analytics dashboards. You will have few enough users to count them. Instrument the events; skip the screens.
- Settings and preferences. Every one is a branch to build and maintain. Pick sensible defaults and wait for someone to complain.
- Notifications everywhere. One email that matters beats a preference centre nobody visits.
- Anything for scale you do not have. Building for a hundred thousand users when you have none is the most common and most expensive mistake in this whole category.
- The second and third user type. Launch for one. It halves the build and sharpens the proposition.
- Onboarding tours. If the product needs a tour, fix the product.
- Automating what a human can do. If ten sign-ups a week need matching, match them yourself. You will learn what the rules actually are, which no amount of specification would have told you.
That last one is the most valuable and the least popular. Doing it by hand for two months is not a shortcut, it is research, and it routinely changes what gets built.
No-code, AI-built, or written properly
| No-code | AI-built | Written properly | |
|---|---|---|---|
| Illustrative cost | $3,000 to $20,000 | $5,000 to $30,000 | $15,000 to $100,000 and up |
| Time to something usable | Days to weeks | Days to weeks | Weeks to months |
| Good for | Testing demand, internal tools, anything with a standard shape. | Getting a working shape quickly, and for founders who can review what was produced. | Anything you intend to run for years, sell to businesses, or that handles sensitive data. |
| Where it hurts | Per-user pricing at scale, and a ceiling you meet suddenly rather than gradually. | Looks finished and often is not underneath. Security and error handling are where it is thinnest. | Slower to start, and you must know what you want. |
| Can you move off it? | Rebuild from scratch. Plan for it. | Sometimes salvageable, sometimes a rewrite. | It is yours, so yes. |
None of these is wrong. Choosing the third when you have not yet proved anyone wants it is the expensive error, and choosing the first for something you will sell to enterprises is the other one.
A word on the middle column, since it is where most founders now start. Modern tools will produce something that works, and the gap between working and shippable is real: authentication done properly, error handling, security, the behaviour when things fail. Is our AI-built app production ready covers what that gap costs to close. Starting there is a reasonable decision; assuming you have finished is not.
Try a prototype first
Before any of the bands above, there is a step that costs a fraction and removes most of the risk. A clickable prototype: the real screens, the real flow, no working software underneath.
Illustratively $4,000 to $12,000 and two to three weeks. You can put it in front of twenty potential users and watch where they hesitate. You can show it to investors. You can hand it to whoever builds the real thing as a specification that is far more precise than a document. And you will change it, several times, at the cost of moving rectangles rather than rewriting software.
Almost every founder we have run this with changed something material about the plan. That is the point, and it is why prototypes before code is where we would rather start with you than at a build.
Where the money goes that nobody budgets
The build estimate is usually the honest part. What catches founders out is everything around it, and the total is frequently a third more than the quote.
- Design. Someone has to decide what the screens look like. Either you pay for it, or the developers do it and it looks like developers did it. Illustratively $4,000 to $20,000 depending on how much there is.
- The services it runs on. Hosting, database, email delivery, error tracking, file storage, payments. Small individually and a real monthly figure together, starting before you have a single paying customer.
- Your own time. The most underestimated input by a wide margin. Expect to spend real hours a week answering questions, reviewing and deciding. A founder who disappears for six weeks gets a product built to guesses.
- The gap between working and launchable. Terms, a privacy policy, cookie handling, a support address, something to do when a payment fails. Individually small, collectively a fortnight nobody planned.
- Changes after real users see it. Not scope creep, the point of the exercise. Reserve a fifth of the budget for what you learn in the first month rather than spending everything on launch.
- Keeping it running afterwards. Roughly 15 to 25 per cent of the build a year, and that begins the day it goes live rather than when you are ready.
The practical implication is that a fifty thousand budget is not a fifty thousand build. It is perhaps thirty-five for the build, with the rest spent on the things above, and a founder who plans it that way is far less likely to run out of money at the exact moment the product finally has users.
Who builds it
Briefly, because it changes the number more than any feature decision. A technical cofounder costs equity rather than cash and brings someone who genuinely cares. An agency costs cash, moves faster at the start, and does not stay. A contractor is the cheapest and the most fragile. A technical cofounder or an agency works through the trade properly, including the version where you do both in sequence.
A note on the number you should actually raise or set aside. Whatever the build costs, plan to have roughly the same amount again available afterwards, because the expensive moment is not launch, it is the three months following it when you know what to fix and cannot afford to. Founders who spend their entire budget reaching launch tend to ship something reasonable and then watch it sit unchanged while the feedback they hoped for arrives and goes unanswered. Half the money before, half after, is a better shape than a bigger first version.
Not for you if
One test we use when a scope feels too large. Ask: if this had to launch in six weeks, what would we cut? Then look at that shorter list and ask honestly why you are not simply building it. Usually the answer is nerves rather than necessity, and the shorter list is the right project.