A fixed-price MVP package should include discovery, design with a clickable prototype, development of a written feature list on one platform, testing, deployment to your own accounts, source code ownership, analytics and error tracking, and a defined support period after launch. It should state what happens when scope changes, what counts as done, and what is paid when. Packages that advertise a low headline price usually exclude discovery, design, the app store cycle, hosting setup and post-launch fixes, and charge for each as a change request. Compare packages by the written scope and the exclusions, never by the headline number.
Prices are in US dollars. Euro and pound figures in parentheses are approximate, rounded conversions. Quotes are issued in the currency of your contract.
"MVP in 8 weeks for $15,000 (€13,000, £11,000)" is an attractive line, and sometimes it is exactly what it says. More often it is the price of a feature list with the expensive parts removed, to be added back as change requests once you are committed. This post sets out what a fixed-price MVP package should contain, what the cheap ones leave out, and the clauses that decide whether a fixed price is actually fixed. Fixed price vs time and materials covers whether a fixed price is the right contract type at all.
What should be inside the package?
| Item | What it should say | Red flag |
|---|---|---|
| Discovery | One to two weeks producing a written scope you approve before the build price is final | No discovery, or a price quoted from a phone call |
| Design | User flows, wireframes, visual design, a clickable prototype, one or two revision rounds | "Design included" with no deliverables named, or templates only |
| Feature list | Every feature named, with what it does, on which platform, for which user type | "Up to 10 screens" or "core features" |
| Platform | Web, iOS or Android, stated. Cross-platform framework named if mobile. | "Mobile app" without saying which or how |
| Testing | Testing against the scope, on named devices and browsers, with a bug-fix period | Testing not mentioned, or "the client tests" |
| Deployment | Set up on hosting, domain and store accounts that you own, with the credentials handed over | Hosted on the agency's accounts |
| Code ownership | Full ownership transfers on payment, repository in your name | Ownership not mentioned, or licensed rather than assigned. See who owns the code. |
| Analytics and monitoring | Event analytics on the core journey, error tracking, backups, all set up | Not mentioned. Without them the MVP cannot do its job. |
| Post-launch support | A stated period, usually four to eight weeks, of bug fixes at no charge, and the rate after that | Support ends at handover |
| Documentation | How to run, deploy and change it, enough for another developer to pick it up | Not mentioned |
What do cheap packages usually leave out?
- Discovery. The price is for a feature list you wrote, which means it is a price for a product that has not been scoped. The real scope emerges during the build as change requests.
- Real design. A template with your logo. Fine for some B2B tools, fatal for consumer products.
- The app store cycle. Submission, review, rejection and resubmission can take two weeks and are often billed separately.
- Third-party costs. Hosting, payment provider fees, email service, app store accounts. Small, but a surprise if unmentioned.
- Accounts and admin. "User login" in the feature list often means a single role with no admin view and no password reset.
- Anything after handover. The first two weeks after launch always need fixes. If they are billed at an hourly rate, the fixed price was not the price.
- Edge cases. The feature works on the happy path. What happens when the payment fails, the upload is too large or the user has no connection is "out of scope".
Red flags in a software development proposal has the longer list, and how to read a software development quote shows how to compare two quotes line by line.
What are the three clauses to read before signing?
- The change clause. What happens when you ask for something not in the written scope. A fair clause says the agency estimates it, you approve it, and it is added at a stated rate or traded for something of equal size. An unfair clause lets the agency decide unilaterally what counts as a change, which turns every clarification into an invoice.
- The acceptance clause. What "done" means. A fair clause ties it to the written scope and a testing period: the feature does what the scope says on the named devices. An unfair clause makes acceptance automatic after a few days of silence, or ties it to the agency's own tests.
- The payment schedule. A fair schedule is milestone-based: a deposit, a payment on design approval, payments at build milestones, a final payment on acceptance, with code ownership transferring on the final payment. An unfair schedule front-loads most of the money before anything is delivered.
How do you compare two packages that look the same?
Put the written scopes side by side and look for what is missing from the cheaper one. Then ask both teams the same three questions: what is not included that I will need before launch, what happens when I ask for a change, and what do I own at the end. The answers usually make the difference clear. A package at $35,000 (€30,000, £26,000) that includes discovery, design, analytics, store submission and six weeks of support is often cheaper than one at $20,000 (€17,000, £15,000) that excludes them all, once the change requests are counted. What a 20k, 50k and 150k budget buys shows what each level should deliver.
When is a fixed price the wrong contract for an MVP?
When the scope is not settled. A fixed price requires a written scope, and a scope written before discovery is a guess. The sound pattern is a small fixed-price discovery, then a fixed price or a capped time-and-materials contract for the build based on what discovery produced. A fixed price for a product with integrations to partners whose APIs nobody has tested is a price that will change.
Before you sign
- Every feature named in writing, with the platform and the user type.
- Discovery, design, testing, deployment and a support period all inside.
- Your accounts, your repository, your code.
- A change clause you can live with.
- Acceptance tied to the scope, not to silence.
- Milestone payments, ownership on the last one.
How 7L prices MVPs
We quote fixed prices after discovery, from a written scope the founder has approved, and the package includes everything in the table above. The change clause works both ways: features can be swapped out as well as in. If you have a package from another team and want to know what it leaves out, send it to us and we will mark it up.
Frequently asked questions
Is a fixed-price MVP cheaper than time and materials?
Not necessarily. A fixed price includes a margin for risk, so for a well-scoped product it can cost slightly more than time and materials would, in exchange for certainty. For a poorly scoped product it is usually more expensive overall, because the gaps become change requests. The scope quality decides which is cheaper.
What is a reasonable price for a fixed-price MVP?
$20,000 to $40,000 (€17,000 to €35,000, £15,000 to £30,000) for a focused single-platform MVP, $40,000 to $80,000 (€35,000 to €70,000, £30,000 to £60,000) for one with accounts, payments and an admin view. Below $15,000 (€13,000, £11,000) look hard at what is excluded. Our post on how much MVP development costs has the full bands.
Can I negotiate the scope down to fit a budget?
Yes, and a good team will help. The right way is to remove features, using the scoping method in our post on how to scope an MVP, not to remove discovery, design, testing or support. Those are what make the features work.
What if the agency says discovery is unnecessary because my brief is detailed?
A detailed brief shortens discovery. It does not remove it. The team still needs to challenge the scope, confirm the technical unknowns and agree what done means. An agency that skips it is quoting your assumptions.
Should the package include a mobile app and a web app?
Rarely for an MVP. One platform first, and a package offering both at a low price is usually delivering a web view wrapped as an app, which is fine for some products and a problem for others. Ask which it is.