Choose an MVP development company on seven things: they have shipped MVPs that launched and are still running, they push back on your scope in the first conversation, they include discovery and design rather than quoting from your feature list, they put the code and accounts in your name, they show working software every one or two weeks, they say what happens after launch, and they can explain their technical choices in plain language. The cheapest quote and the most impressive portfolio are both poor signals. The team that talks you out of a feature in the first call is usually the right one.
Prices are in US dollars. Euro and pound figures in parentheses are approximate, rounded conversions. Quotes are issued in the currency of your contract.
Choosing the company that builds your MVP is the largest decision in the project, and founders make it on the two weakest signals: price and portfolio. Price tells you how small the team's reading of your scope is. Portfolio tells you what they can make look good in a case study. Neither tells you whether they will ship a product that teaches you something. This post gives you the seven things that do, what a good first call looks like, and the questions to ask when you have a shortlist.
The seven-point checklist
| Check | What good looks like | How to verify |
|---|---|---|
| 1. They have shipped MVPs that are still running | Several products that launched, got users and continued. Not just features for large clients. | Ask for three launched MVPs and the founders' contact details. Call them. |
| 2. They push back on scope | In the first call they ask what the core journey is and suggest cutting something. | Bring your feature list. If they accept all of it, they are quoting, not scoping. |
| 3. They include discovery and design | A short discovery phase producing a written scope, and real design with a tested prototype. | Ask what you receive at the end of discovery and whether the price is final before it. |
| 4. You own everything | Repository, hosting, domain and store accounts in your name from day one. Ownership assigned on payment. | Ask for the clause. See who owns the code. |
| 5. Working software every one or two weeks | Demos of running product, not slides, with your feedback between them. | Ask to see the cadence from a current project. |
| 6. A plan for after launch | A support period, a rate for version two, and help with the first hire if you want it. | Ask what happens in week one after launch and who pays for it. |
| 7. Plain-language technical answers | They explain the stack, the data model and the hosting in terms you understand, and say why. | Ask why they chose the stack. A clear answer is a good sign. Jargon is not. |
What does a good first call look like?
You talk less than you expected. The team asks about the problem, the user, how you know the problem is real, what the user does today instead, and what the one thing the product must do is. They ask about budget and timeline early and without embarrassment. They tell you something you did not want to hear, usually about a feature that should wait or a platform you do not need yet. And they describe what discovery would produce and what it costs, rather than quoting the whole build from the call. A first call where the team mostly presents their portfolio and then asks for your feature list to quote against is a sales call, and the quote will be for the smallest version of what you said.
What questions expose a team that only ships features?
- "What would you cut from my list?" A team that has shipped MVPs has an answer immediately. A team that builds to spec says it depends.
- "How will I know whether the MVP worked?" The right answer names activation and retention and says analytics are in the scope. The wrong answer is about delivering the features.
- "What happened to the last three MVPs you built?" Listen for whether they know. Teams that care about outcomes stay in touch with founders.
- "Tell me about an MVP that failed." Every experienced team has one. A team with none either has not shipped many or is not being honest.
- "Who on your side will I talk to each week, and have they built an MVP before?" The senior person who sold you the project may not be the one who runs it.
- "What do I need to have ready, and when?" Content, decisions, access to users. A team that has done this knows what it needs from you.
Questions to ask before hiring an app development company has the general list, and these are the MVP-specific ones.
How do you compare a shortlist of three?
- Send the same written scope to all three. One to three pages: problem, user, core journey, the feature list with in and out. How to write an app brief shows the format. Different briefs produce incomparable quotes.
- Compare what each includes, not what each costs. Discovery, design, testing, deployment, support period, ownership. How to read a software development quote and what a fixed-price MVP package should include are the two posts to read with the quotes in hand.
- Call a reference from each. Ask the founder what went wrong, how the team handled it, and whether they would use them again.
- Weigh the pushback. The team that challenged your scope most usefully in the first call is the one that will keep doing it, which is what saves money in the build.
- Check the red flags. Red flags in a software development proposal lists them. One is enough to walk away.
What should you not optimise for?
- The lowest price. It is the price of the smallest interpretation of your scope, with the rest arriving as change requests. The cheapest MVP is the one that teaches you the most per dollar, which is rarely the one with the lowest quote.
- The biggest logos. Enterprise work is a different skill from shipping an MVP in twelve weeks. A portfolio of large clients can mean a team that has never been fast.
- Location. It matters less than the weekly rhythm and the project manager. Teams in other time zones ship excellent MVPs when the process is right.
- Technology brand names. A team that leads with the newest framework is selling their preference. The stack for an MVP should be boring.
- Speed promises. Four weeks for a product with accounts, payments and an admin panel is a prototype or a lie. Eight to sixteen weeks is honest.
Choose the team that
- Has shipped MVPs you can call about.
- Cut a feature from your list in the first call.
- Includes discovery, design, analytics and support.
- Puts everything in your name.
- Shows working software every one or two weeks.
- Explains the technology in plain words.
- Tells you what happens after launch.
How 7L measures up
We would rather you ran this checklist on us than took our word for it. Our MVPs run through the Startupper Program, discovery is a separate short engagement with a written scope at the end, the code and accounts are yours from the first day, and we will give you founders to call. We cut features in the first conversation because it is the most useful thing we can do in it. If you have a scope or a feature list, send it over and see what we say.
Frequently asked questions
Should I choose a specialist MVP agency or a general software company?
Choose on whether they have shipped MVPs recently and can prove it, whatever they call themselves. A general company with a track record of fast first releases is fine. A self-described MVP specialist with no launched products to show is not.
How many companies should I shortlist?
Three. Enough to compare, few enough to give each a proper conversation and a reference call. Send all three the same written scope and compare the inclusions, not the price.
What should an MVP development company cost?
$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, from a team that includes discovery, design, testing and support. Our post on how much MVP development costs has the full breakdown.
Is it a bad sign if the company wants to charge for discovery?
It is a good sign. Discovery is real work that produces a written scope and an accurate price, and charging for it means the team takes it seriously. A free discovery is usually a sales call. Discovery should cost a small fraction of the build and should be usable with any team if you decide not to continue.
What if the company I like is more expensive than the others?
Compare what is included. A higher price that includes discovery, design, analytics and six weeks of support is often cheaper than a lower one that excludes them, once change requests are counted. If the inclusions are the same and one is simply more expensive, ask why. The answer may be a stronger team or a larger margin, and the reference calls will tell you which.