"How much will it cost?" is the first question almost every founder asks, and the honest answer — "it depends" — is useless on its own. This post replaces it with something you can work with: the handful of things that really move the price, a way to estimate your own MVP in hours, and the decisions that make it cheaper without making it worse.
What an MVP is (and isn't)
A minimum viable product is the smallest thing that lets real users get real value, so that you can learn whether the idea works. It is not version 1.0 with fewer colours. The test for every feature is simple: if we leave this out, can we still learn what we need to learn?
That definition matters for cost, because most budget overruns come from building things that answer no question.
The five things that drive cost
1. The number of distinct user flows
Price follows flows, not pages. "Sign up, create a project, invite a teammate, pay" is four flows. Each one needs design, front-end, back-end, edge cases and testing. A ten-page marketing site with no logins can be cheaper than a three-screen app with accounts.
2. Who the users are
One kind of user is the cheapest case. Two sides — buyers and sellers, students and teachers, clients and an admin — roughly doubles the surface: separate dashboards, permissions, notifications and onboarding for each.
3. Integrations
Payments, email, maps, calendars, CRMs, AI models. Each integration is usually small to start and expensive to get right: webhooks, retries, failure states, test accounts, and the day the provider changes its API. Budget for every integration separately.
4. Content and data
Who writes the copy? Is there data to import? Does someone need an admin panel to edit things after launch? "We'll figure out the content later" is the single most common reason launches slip.
5. Platform
A responsive web app reaches everyone with one codebase. Native iOS and Android apps double the build and add store review. For most MVPs, a fast web app (optionally installable as a PWA) is the right first step.
Estimate it yourself, in hours
Hours are more useful than prices, because rates vary widely by country and seniority while the work does not. Here are typical ranges for one experienced full-stack developer-designer; multiply by whatever rate you're quoted.
| Piece of work | Typical hours |
|---|---|
| Discovery, scope and user flows | 8–20 |
| UI/UX design of the core screens | 20–60 |
| Landing page / marketing site | 20–50 |
| Accounts: sign-up, login, password reset | 10–25 |
| Each core user flow (CRUD + UI) | 15–40 |
| Payments (subscriptions or one-off) | 15–35 |
| Admin panel for content or users | 15–40 |
| Each third-party integration | 8–30 |
| Email notifications | 6–15 |
| QA, fixes and launch | 15–30 |
A typical single-sided SaaS MVP — landing page, accounts, two or three core flows, payments, a simple admin — lands somewhere around 150–350 hours. A marketplace with two user types often lands at 300–600.
These ranges are wide on purpose. The low end assumes clear decisions and finished content; the high end assumes the scope moves during the build.
Where the money really goes
- Changing your mind mid-build. Not a problem in itself — learning is the point — but changes after something is built cost several times more than changes on paper. Spend more time on flows and wireframes and the build gets cheaper.
- Custom everything. A custom design system, custom auth and a custom CMS are rarely what makes an MVP succeed. Proven building blocks (a hosted auth provider, Stripe, a headless CMS or plain Markdown) are faster and more reliable.
- Edge cases nobody will hit yet. Multi-currency, ten user roles, offline mode. Write them down for later.
- No owner on the client side. When nobody can make a decision within a day, the project waits, and waiting is billed too.
How to make it cheaper without making it worse
- Write one sentence that defines success. For example: "Ten paying teams use it weekly by the end of month two." Every feature is measured against it.
- Cut to one user type. Launch the seller side with a concierge process for buyers, or the other way round.
- Fake the back office. An admin panel can be a spreadsheet and a few scripts for the first months.
- Design the core screens properly, and only those. Good UX on the three screens people use every day matters far more than a polished settings page.
- Pick a stack the next developer can work with. TypeScript, React or Next.js, a managed database and a standard host keep your options open.
Fixed price or hourly?
A fixed price works when the scope is genuinely fixed: a clear brief, finished designs, no unknown integrations. A time-and-materials or weekly-retainer arrangement works better when you expect to learn and change things — which, for an MVP, is usually the case. A common compromise is a fixed-price discovery and design phase, followed by an estimated build with a weekly cap.
A quick checklist before you ask for quotes
- One sentence describing the user and the problem
- The success metric for the first three months
- The list of user flows, ranked by importance
- Integrations you know you need
- Who provides the content and when
- Your budget range and launch date
With those six things in writing, quotes become comparable — and much more accurate. If you want a template for that document, see the website brief that gets accurate quotes.
Summary
An MVP's cost is driven by flows, user types, integrations, content and platform — not by page count. Estimate in hours, cut to one user type and one success metric, use proven building blocks, and decide quickly. That's how a small budget turns into something people actually use.
If you'd like a second opinion on your scope, get in touch — I'm happy to look at it.
