Nobody can give you a price from an article. What you can work out is the effort, and effort is the half that is actually knowable: an MVP with accounts, payments and an admin area is somewhere around six to thirteen developer-weeks. Multiply that by a day rate you have really been quoted and you have a budget built on something. Everything below is how to get both halves.
If you came here hoping for a number, that is the honest version of one. Read on for why the other kind is worthless.
Why "an MVP costs $X" is always wrong
Search this question and you will find confident answers: an MVP costs $15,000, or $40,000, or $80,000. Those numbers are produced by a calculator that has no idea where you are, what you are building, or who you are going to hire.
Three variables move the total by more than an order of magnitude, and none of them are knowable from a web page:
- Where your developer is. The same work is priced completely differently in different markets, and both prices can be fair.
- What "MVP" means to you. Some people mean a landing page with a waitlist. Some mean a working product with payments, an admin area and two mobile builds. Those are not the same project and no average covers both.
- How much risk is being priced in. A fixed quote against a vague brief includes a padding for everything that might go wrong. A fixed quote against a clear one does not need it.
So a single number is meaningless. A number you build yourself, from an effort estimate and a rate you sourced, is not.
Step one: work out the effort
Effort is the part that can be reasoned about from a scope. Break the project into what it actually contains and estimate each piece, rather than trying to price the whole thing at once.
A rough shape for a web MVP:
| Piece | Developer-days |
|---|---|
| The core app itself | 15 to 30 |
| Accounts and login | 3 to 6 |
| Payments or subscriptions | 4 to 10 |
| An admin area to manage things | 4 to 10 |
| Setup, testing and launch | 3 to 7 |
That is roughly 29 to 63 days, or six to thirteen weeks, for one developer. Add design if you do not have it. Add a good chunk more if you are shipping to iOS and Android rather than the web.
Two things about that range are worth sitting with. It is wide, because estimating without requirements is genuinely uncertain and a narrow range would be a lie about how much is known. And most projects land nearer the top of it, because the surprises are the job.
Step two: get a real rate
This is the part you have to do yourself, and it takes an afternoon. Ask three developers what they would charge for a defined piece of work. Not "what is your rate", which invites a non-answer, but "what would you charge to build X, and what would you need from me to be confident in that number".
You will get three different figures. That spread is information: it tells you what the work is really worth, and the reasoning behind each number tells you who has thought about it.
Then multiply. Twelve weeks at 60 days, against whatever a day costs where you are hiring, is your budget.
What the estimate does not include
The effort number stops at launch. Things that reliably land outside it:
- Hosting, domains and third-party services. Usually small, never zero.
- App store developer accounts and review time.
- Content. Copy, photography, product data. Someone has to make it and it is rarely the developer.
- Maintenance. Software is not finished when it ships.
- Your own time. Answering questions quickly is most of what keeps a project on schedule.
The mistake that actually costs money
It is not paying too much per day. It is buying the whole thing at once.
Whatever the total says, do not commission twelve weeks of work from someone you have never worked with. Buy the first slice: one defined piece, its own price, a week or two. If it goes well the second slice is easy and you have found someone you can call again. If it goes badly you are out a week rather than a quarter.
That single decision removes more risk than any amount of negotiating on the rate.
What to do with the number
Take the breakdown to the conversation. Ask developers to quote against the same lines you estimated. Where their number differs from yours, the gap is the interesting part, and it is almost always a piece one of you is not counting: the admin area, the second platform, the launch work.
A scoped brief gets a real quote. "How much for an app?" gets a shrug or a padded guess.
If you want the brief itself to be right, the brief builder turns a handful of answers into something a developer can read and quote from. And how to hire a freelance developer without Upwork or Fiverr covers the rest of the process: shortlisting from work you can open, checking a person is real, and structuring that first slice so it can fail cheaply.