BLOG

How to Choose an MVP Development Company: Five Criteria That Reveal Validation Design

When you look for a company to build an MVP (a minimum product for validating an idea), there are plenty of candidates and no obvious way to compare them. Size, price, number of past projects: if you choose by the easy-to-compare items, you sign without knowing whether the company can do what an MVP needs most, which is designing the validation.

Eric Ries, who popularised the idea, defines an MVP as "that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort." The point is learning, not making the product small. What MVP development is and how it differs from a PoC are covered in separate articles, so this one focuses on choosing who to outsource to.

This article sets out five criteria to check before you outsource, with what to ask in the first meeting and examples of answers. It also covers what changes the cost, rights and account ownership, and company types. It draws on our experience of building our own project management tool, projectAI, and of launching clients' new services.

Choose an MVP partner by what it will not build: validation design over size and price

About the author

wesionaryTEAM Editorial Team

The editorial team is made up of wesionaryTEAM's project managers and engineers. Drawing on what we learn every day on business system, AI adoption and digital transformation projects, we publish information people can use when making decisions, with cases and figures.

How MVP projects usually fail

MVPs fail more often at the commissioning stage than at the technical one. Three patterns recur.

  • A quote is taken from a feature list, and features the validation does not need get built.
  • The product is released and then left, with no team to watch user reactions and fix things.
  • The cost of additions and of going to production is not settled at the start, and the budget grows mid-way.

The reasons businesses stop point the same way: whether anyone wants the product comes before how well it is built. CB Insights' analysis of 431 VC-backed companies that shut down since 2023 found running out of capital at the top with 70%, but calls that the final cause of death rather than the root problem. Among the more telling causes it names poor product-market fit, at 43%.

Five criteria for choosing an MVP development company, and the answers to listen for

For each criterion, here is what to ask in the first meeting and examples of answers. The examples are our own view.

1. Does the conversation start from the hypothesis and the metrics?

  • Ask: What must this MVP prove? What would you need to learn in order to continue?
  • Good answer: restates the hypothesis in one sentence, names two or three numbers to watch, and proposes setting the rules for continuing, fixing or stopping before launch.
  • Risky answer: "Send us the feature list first." "Let's look at the criteria together after launch."

2. Does it propose cutting features?

  • Ask: Which features can be dropped? Is there a way to test this without building it?
  • Good answer: names features and explains why the hypothesis does not need them, and says authentication, personal data and payment protection will not be cut.
  • Risky answer: "We can include everything you asked for." "It's an MVP, so security can wait."

3. Are the conditions under which costs change clear?

  • Ask: When does the cost change? What do you expect going to production to cost?
  • Good answer: explains additions, changes of direction and going to production for each contract type, and puts a rough production estimate and its assumptions in writing.
  • Risky answer: "We'll quote each time." "Let's think about production once it's built."

4. Can the team continue after launch, and can you leave at any time?

  • Ask: Who carries on after launch? If we move to another company, what do we receive?
  • Good answer: names the people and the setup, and states on the spot the terms for handing over code, accounts, documents and data.
  • Risky answer: "Maintenance is a separate team." "We'll register the accounts in our name."

The company that builds an MVP is not always the right one for full development. Being able to continue with the same team and being able to leave at any time are both worth securing.

5. Does it have experience with the same kind of validation?

  • Ask: In the same kind of validation, what did you drop, what did you measure and how did you decide?
  • Good answer: says whether the case tested demand, continued use, fit with operations or technical feasibility, and goes as far as the features dropped and the numbers watched.
  • Risky answer: "We have this many projects in your industry." Or it ends at "We launched it."

The validation design on one page

A validation design is not a complicated document. These five items are enough. This is an illustration, and the thresholds have no evidence behind them.

  • Hypothesis: parents who book a class by phone will switch to booking by smartphone.
  • Who and how long: parents at one existing class, for four weeks after launch.
  • Numbers to watch: share of bookings by smartphone, whether parents book a second time, number of phone calls.
  • Decision: above 50% continue, 20-50% fix the flow, below 20% stop.
  • What not to build: payments, detailed notification settings, separate admin permissions.

A company that can fill in these five with you in a meeting can design the validation.

How cost is set, and the conditions that change it

We found no neutral statistics specific to MVPs. Published price ranges rest on different assumptions depending on the author, so lining up the amounts does not make them comparable. The amount is moved by assumptions such as the number of screens and user roles, external integrations, whether there is a smartphone app and how much post-launch operation is included. The thinking is set out in the cost section of What Is MVP Development?

Before the amount, look at the events that change it. They are handled differently depending on the contract.

EventFixed-priceQuasi-mandate
Adding or changing featuresChange procedure and an extra quoteAbsorbed by reordering priorities for the next period
Change of directionAssumptions change; re-quoteSame team builds something different
Going to productionSeparate quote; check the rough figure firstCheck first: rebuild or reinforce

For an MVP whose specification will move, a quasi-mandate contract, where you pay for the work rather than a fixed deliverable, is the norm. The agile model contract from Japan's Ministry of Economy, Trade and Industry and the Information-technology Promotion Agency assumes this form, noting that a fixed price can give the vendor a reason to hold back additions and changes. A quasi-mandate does cost more if the period is extended. Where the deliverable and deadline can be fixed, a fixed-price contract is also an option.

Rights and account ownership

Handovers stall on rights and account ownership more readily than on technology. Before signing, confirm these six in writing.

  • Who holds the copyright in the source code.
  • Who owns the place the code is kept (the repository).
  • Whose name the domain, servers and app store accounts are in.
  • Whose name the contracts for external services such as payments, email and analytics are in.
  • Whether usage data can be taken out.
  • Which design documents and architecture diagrams are handed over.

Under Article 61(2) of Japan's Copyright Act, when copyright is assigned, the rights to adapt the work (Articles 27 and 28) are presumed to stay with the assignor unless the contract specifically mentions them. So check that the contract names those articles rather than simply saying "copyright is assigned". The wider contract checklist is in What Is Contract Development?

Which type of company fits which project

Companies that offer MVP development fall into roughly four types by how they work. Fee structures tend to differ too, so it is practical to identify the type first and confirm the details in a meeting.

  • Large, end-to-end. One company takes the project from concept through full development. Suits new ventures at large companies. Fixed-price quotes are common, so check whether it proposes narrowing the scope at the MVP stage.
  • New-venture support. Starts from business concept and validation design. Suits business units without an in-house development counterpart. Quasi-mandate and monthly fees are common, and full development may be assumed to go elsewhere.
  • Small and fast. Includes no-code specialists and individuals. Suits startups that want to release something small and decide early. Check first whether going to production means a rebuild, and who supports the product after launch.
  • Co-creation. Works as one team with the client rather than as vendor and buyer. Suits companies looking for a partner that shares the outcome of the business. Fees may be linked to results, so check what qualifies and on what terms.

Which type to choose depends on what you want after the MVP.

Why we build MVPs as co-creation

We use co-creation so that an MVP does not become a build-and-hand-over job. Every week you see a working version, and together we decide priorities and what not to build. Decisions are recorded in a project management system you see on the same screen, so the reasoning can be traced later.

The form of the fee depends on the project. For a new-business launch, we sometimes charge nothing until launch and continue on a monthly fee and revenue share. Where that does not work, we proceed on a quote.

Three examples.

  • The Q&A service Question Market was narrowed to the features the hypothesis needed and released about three months from concept.
  • The admissions matching service Nennai Nyushi Navi has the same team adding generative AI features step by step after release. The operator reports users up 11 times year on year.
  • A membership system for a youth soccer club had its foundation set up in days and took in more than 20 requests from the field in about a month.

More cases are under new venture and startup case studies. The process is on MVP and PoC development, and continuing into full development is covered under system development.

FAQ

What are the pros and cons of outsourcing MVP development?

The upside is that you can start validating without a development team of your own. The downside is that if you hand over the decisions too, the learning does not stay in your company, so keep the hypothesis and the decisions in-house.

What does MVP development cost?

We found no neutral statistics specific to MVPs. The amount moves with assumptions such as the number of screens and external integrations, so align the assumptions before comparing quotes. With us, a free estimate consultation sorts out those assumptions.

Should I choose a large company or a small one?

It depends on what you want after the MVP. The same company through full development: large end-to-end. Ship small and decide early: small and fast. A partner that shares the outcome: co-creation.

Fixed-price or quasi-mandate?

Quasi-mandate is more common for an MVP whose specification is expected to change. Where the deliverable and deadline can be fixed, fixed-price works too. Either way, confirm the conditions that change the cost and the rights to the deliverables first.

Can I commission only the MVP and move to another company afterwards?

Yes, but unless the code, design documents, account ownership and rights are settled at the start, the handover stalls.

Summary

What to look for in an MVP development company is not size or price but whether it can design the validation. Companies that start from the hypothesis, propose cutting features, and state up front what changes the cost and who holds the rights are the ones whose MVPs do not end as a one-off build.

Ask the five criteria in the first meeting and judge the company by its answers. We answer the same five on the spot, and you can ask a project manager in a free estimate consultation. To discuss the way of working first, contact us.

Related articles and pages

Sources

Reviewed by

Ichiro NagataCEO and Representative Director

A former engineer at Yahoo! JAPAN. For more than 18 years at startups and large companies, he has worked on a wide range of projects, from new consumer and business ventures to the digital transformation of operations. Alongside hands-on development as an engineer, he has built and managed teams, designed businesses and tested hypotheses, gaining broad experience in launching and growing businesses. He has been through three business sales. Convinced that co-creation makes products better and lets ideas be tested in the market, he founded wesionaryTEAM to offer a co-creation platform.