Most MVPs are not minimum and not viable. They are a full product with a smaller logo, priced at 50,000, built over five months, before a single customer has paid. That is not an MVP. That is a bet with your savings.
An MVP exists to answer one question: will people use this and pay for it. The cost should match that goal, not the size of your ambition.
What an MVP should actually cost
If your MVP quote looks like a full product quote, the scope is wrong. Real ranges for a focused first version:
- One core flow, live, real users: 5,000 to 10,000.
- Two or three connected flows with basic auth: 12,000 to 30,000.
- "Everything the competitor has" rebuilt upfront: 60,000 and a high chance you built the wrong thing.
The first row is where you want to be. It is enough to put something real in front of users and learn fast.
Validate before you build
You do not need code to test demand. Before you spend anything on development, prove people want it:
- Sell it with a landing page and a waiting list.
- Run the service manually over WhatsApp, email, or a spreadsheet for your first ten users.
- Take three sales calls and see if anyone commits.
If nobody bites with a manual version, code will not save it. If people are already pushing you to make it faster and smoother, that is your signal to build.
How to cut scope to a first brick
The skill is not adding features. It is removing them until one essential flow remains. Use this filter:
- One user type. Build for the person who feels the pain most. Ignore the rest for now.
- One core action. The single thing that delivers value. Everything else is a distraction.
- One metric. Decide upfront what proves it works: signups, repeat use, a paid order.
Six screens is plenty for a first brick. If your plan has thirty, you are building version three before version one has taught you anything.
When no-code is enough, and when it is not
For a throwaway prototype to test an idea, no-code is fine and often the smart choice. Build it in a weekend, show it to users, throw it away.
The moment real customers depend on it, the calculus changes. When you need to own the code, connect to payments, handle real authentication, or integrate with systems you do not control, a no-code prototype becomes a ceiling. That is when you move to a real application you can maintain and extend. We cover the line between the two in our guide on custom web applications.
A concrete example
A founder wants a marketplace: buyers, sellers, messaging, payments, reviews, mobile apps. Priced whole, that is 90,000 and six months before launch.
The first brick is much smaller. Sellers list one item, buyers see the list, a contact button connects them. No payments yet, no reviews, no app. Live in two weeks for 5,000. If sellers list and buyers contact them, the demand is real and the next brick is worth building. If not, the founder saved 85,000.
Build the smallest version that proves the idea, then iterate on what users actually do. Get a fixed-price first brick delivered in two weeks at 5000.dev.