What Is MVP Development? Process, Cost and How It Differs from a PoC

"Our new business plan was approved. But internally, we can't decide what to build first, or how far to take it."

"We were told to start small, so we made it small. What we ended up with didn't resonate with anyone."

"We got estimates from three companies, and they ranged from ¥3 million to ¥12 million. We thought we had asked for the same thing, but we can't tell what's different."

When we receive consultations about developing a new business, comments like these are where they start. All of them come from a misunderstanding of the term "MVP development."

MVP stands for Minimum Viable Product. MVP development is an approach in which you build a product with only the minimum features needed to test a business hypothesis, and then decide based on how real users respond. It applies Lean Startup thinking to product building, and it tests two things: the value hypothesis, "is there a reason to keep using it?", and the market hypothesis, "is there a market we can reach?"

In this article, we lay out from the perspective of a development partner what MVP development is, how it differs from a PoC (proof of concept) or a prototype, how to proceed, and what determines its cost and timeline. We also cover how the premise of MVP development has changed now that AI-driven development has become the norm. This is a part we (wesionaryTEAM) can write about from our experience of building an AI business tool for our own use.

What MVP Development Is: Don't Misread "Minimum"

MVP stands for Minimum Viable Product. It is an approach where you build only up to the minimum form that delivers value to users, and confirm through real reactions whether your business hypothesis is right.

Most stumbles begin with taking this "minimum" to mean building a finished product cheaply and small. That gives you a half-baked product with features simply cut away. The "we made it too small and it didn't resonate with anyone" from the start of this article comes from this interpretation.

Correctly understood, it means narrowing down to one hypothesis you want to test, and building only the parts needed to test it, at a quality that actually reaches users. The criterion for cutting is not "is it cheap?" but "is it needed to test this hypothesis?"

For example, if you want to find out whether store staff will enter their paper daily reports from a smartphone, all you need is an input screen and a way to save the data. A summary screen for managers, permission management and integration with other systems are not needed to test this hypothesis. Conversely, if you skimp on the usability of the input screen, you can no longer test the hypothesis at all. What you can cut is scope, not quality.

The Difference Between an MVP, a PoC and a Prototype

These three often get mixed up in practice. Their purposes differ, so mixing them leads to wrong decisions. Put very briefly, a PoC tests "can it be built?", a prototype tests "can it be used?", and an MVP tests "will it be used?"

MVP development is sometimes discussed alongside agile development, but that is a different axis. MVP development concerns purpose, "what to test," while agile development concerns process, "how to build and proceed." MVP development is sometimes run with agile development and sometimes not. They are not opposing concepts.

PoC stands for proof of concept, and it tests whether an approach can really be achieved. Technical checks such as whether AI can read handwritten slips, or whether data can be extracted from an existing core system, fall into this category.

What is often overlooked is that a successful PoC does not necessarily become a business. Being technically able to read something and having the frontline keep using it are separate questions. In many projects that stop at the PoC stage, the questions being tested leaned toward the technical side from the start, and no business-side question was ever posed.

As for the order: if there is uncertainty in the technology, do a PoC; if there is uncertainty about business viability, do an MVP; if you are unsure about the look or the flow of operations, do a prototype. You don't have to do all three in sequence. You choose based on what the biggest uncertainty is right now.

Building an MVP Isn't Just Writing Code

People tend to assume an MVP means starting development right away, but depending on the hypothesis, you can test it without building a product. Here are the methods actually used, in order from the least to the most to build.

Building only an announcement page: You publish just a page describing the service and a sign-up form, and see how many people sign up. Use this when you want to confirm whether anyone will pay to solve this problem. You build one page.

Having people work manually behind the scenes: To users it looks as if a system is doing the processing, but in reality staff handle it by hand. For a matching service, for example, staff initially put matches together by hand and send them back. You can confirm whether people see value in what you offer before building the mechanism.

Combining existing tools: You run the service by connecting things that already exist, such as forms, spreadsheets and chat tools. This is effective when you want to confirm whether the business flow itself works.

Building just one feature: You implement only the core feature. At this point it becomes ordinary development, but with a narrowed scope.

The first three let you test business-side hypotheses without spending on development. It is worth pausing at the start to check whether you are jumping straight to the fourth. The failure mentioned at the beginning, "we made it too small and it didn't resonate with anyone," often happens as a result of cutting features using the fourth method, and in some cases trying the first three would have produced different lessons.

How to Proceed with MVP Development

1. Decide on one hypothesis to test

Narrow it down until you can write in one sentence "whose problem, what problem, and how you will solve it." If there are several, every later decision will waver.

Of the two hypotheses mentioned earlier, test the value hypothesis first. A product with no reason to keep using it won't grow, however big the market. Testing the market hypothesis can wait until the value hypothesis passes.

At this stage, the hypothesis isn't the only thing to decide. You also decide up front what outcome will count as success. Make it something that can't be interpreted differently later, such as "60% of registered stores are still entering daily reports in week two." Without this criterion, discussion after release ends with "it's being used reasonably well," and you can't make the next decision.

When setting the criterion, include both a number and a deadline. "60%" alone splits interpretations over "60% as of when?" Also decide the base population in advance. Whether it is "of stores that registered" or "of stores we approached" changes what the same 60% means.

Once you have decided all this, the measurements needed for testing also become clear, such as needing a mechanism to record how many times daily reports are entered. Measurement mechanisms are part of the MVP scope. You can't test what you can't measure. We often see cases where this is cut and, after launch, the team ends up with "it feels like it's being used, but we have no numbers."

2. Choose only the features needed to test the hypothesis

List the features and ask of each one, "can we not test the hypothesis without this?" Drop everything that is merely "nice to have." This is fastest when the ordering side and the building side do it together. If the building side decides alone, the business intent gets lost; if the ordering side decides alone, the sense of implementation effort gets lost.

3. Build it

Speed matters in MVP implementation, but building it so it can be thrown away later matters just as much. It is not unusual to change direction as a result of testing. Structure the product so that when that happens, you aren't held back by "but we went to the trouble of building it."

Specifically, build the parts you want to test separately from the parts you don't. For parts that can be reused even if you change direction, such as authentication and data storage, use existing mechanisms. Conversely, keep the part at the center of the hypothesis separate from everything else, on the assumption that it will be rebuilt.

What we ask of the ordering side at this stage is not to stall decisions. Most of what stretches an MVP's development period is not implementation but "waiting for confirmation." Whether you can set up a routine of looking at something working at least once a week and deciding on the spot greatly affects the timeline.

4. Have real users use it

Don't stop at internal testing. People inside the company know the context, so they can use even confusing screens. Feedback that "we could use it" does not mean outside users can use it the same way.

You don't need many people. Even 10 to 20 users will show you usage trends. More important than the number is whether they are genuinely the users you have in mind. If you ask acquaintances to try it, you get favorable reactions, which leads to wrong judgments.

At this point, look not only at the numbers but also at the scenes of use: where people's hands stopped and what they skipped. Numbers tell you what happened, but not why.

5. Decide

Measured against the criterion set in step 1, decide whether to continue, change or stop. Being able to decide to stop is the value of MVP development. That is why the initial investment is kept small.

In the decision meeting, it is essential not to move the criterion after the fact. If a discussion starts along the lines of "we didn't reach 60%, but it's growing," that is redrawing the criterion. If you want to look at growth, decide from the beginning on "60% by week four."

Even when you continue, decide what to test next before moving on. If you shift to "just keep building it out" without deciding this, everything from then on becomes development without a hypothesis.

Cost and Timeline: What Determines the Price

Let's go back to the "ranged from ¥3 million to ¥12 million" from the beginning.

Published information on the going rate for MVP development varies widely, even when you simply line it up. The table below lists the guideline figures published by each company as of 2026, as they are.

Note: The source article lists AI-assisted development as a separate item, but whether AI is used is a difference in how something is built, not a category of development method. Here we have therefore merged it into scratch development and show the combined range of both.

Even for the same "MVP development with no-code," some articles say ¥100,000 and others say ¥5 million. It is not that one of them is wrong. The scope that the term "MVP" refers to differs from writer to writer. The "ranged from ¥3 million to ¥12 million" at the start is the same thing happening within a single project.

Note that operating costs are separate: cloud usage fees, databases, payment service fees and so on. Published guidelines mention figures from tens of thousands of yen per month for small setups to hundreds of thousands of yen per month at larger scale. If you budget for operating costs during the testing period as well, you avoid having to stop partway through testing.

The main factors that move the price are as follows. When comparing estimates, you can judge better by looking at how each company set these assumptions than at the amount itself.

• Number of screens: This has the most direct effect. Three screens and thirty screens are different stories
• Types of users: Only general users, or also administrators and approvers? Once permissions come into play, the amount of design work changes
• Integration with external systems: Payments, authentication, maps, existing core systems. Each additional integration adds spec checks and exception handling
• Migration of existing data: Whether there is a migration changes the assumptions. If existing data is of poor quality, the migration itself becomes a project
• Supported devices: Web only, or smartphone apps as well? If you release an app, allow time for app store review
• How critical uptime is: Requiring high availability or audit logs at the testing stage goes beyond the scope of an MVP
• Operations setup after launch: Who takes inquiries, and who fixes things? If you proceed without deciding this, things stall after launch

The Same Plan Becomes Something Else Depending on Scope

Using the daily report app from earlier as an example, let's compare two estimates.

Scope A (focused on testing the hypothesis) One input screen for staff, photo attachments, saving, and a simple list to check input status. Login uses an existing account platform. The target is three of the company's own stores. Aggregation is done by hand after exporting to a spreadsheet.

Scope B (the result of gathering requests from across the company) Everything in A, plus a summary screen for managers, per-store permission management, an approval flow, integration with the existing attendance system, digitizing two years of past paper daily reports, iOS and Android apps, and audit logs.

Both are called "an MVP of a daily report app." But the amount to build differs several-fold, and the number of specifications to confirm differs even more. The "ranged from ¥3 million to ¥12 million" from the start is, in many cases, this situation. Each company is estimating a different scope, with no ill intent.

When comparing, align each company's assumptions on the factors listed above before lining up the cost breakdowns. That alone gives you estimates you can compare.

Note that the items in Scope B are not unnecessary. They are things you will need after passing the test. It is a question of order.

About the Timeline

If the scope is well narrowed, a few weeks to about three months is a rough guide. However, what stretches the timeline is more often waiting time while specifications remain undecided than the weight of implementation. The next section is about that.

How Building projectAI In-House Changed the Premise of MVP Development

We built "projectAI," an AI business tool that supports project progress, for our own use, and we use it daily in-house. As we announced in July 2026, we implemented 73 screens and 31 AI features in about 4.5 months. We also built an internal tool called "cockpit" that runs multiple AI agents together, and we drive development itself with AI.

What this experience tells us is clear.

Because implementation has become faster, we can now spend time thinking about what the specifications should be.

Previously, implementation took up most of the time. Discussions of what to build had to be cut short within limited time, and we repeatedly made calls like "let's build it this way for now and fix it later." That allocation has reversed. The time saved on building can now go straight into considering "is this really necessary?" and "is there a better form?"

As a result, we feel the quality of what we build has improved. Cases where we built everything out on hastily decided specifications have decreased.

At the same time, new care is needed. Previously, the weight of implementation acted as a brake on debates about whether to add a feature. A single remark like "adding that will push things back two weeks" helped narrow the scope. That brake has weakened. Whether you spend the freed-up time on considering what things should be, or on building more of what can be built, makes a big difference to the outcome.

We have decided to use it for the former. We spend time deciding what not to build, and finish the building work fast. That is how we allocate it.

Another change is that deciding to throw things away has become easier. Because the burden of rebuilding has dropped, the psychological barrier to changing direction based on test results has become smaller. We feel reality has caught up with the original aim of MVP development: "learn fast, change fast."

Third, there is more room to raise the quality of testing. Measurement and usage analysis that we used to give up on because of effort can now be built in from the MVP stage. Since testing is the purpose, being able to cover this has no small effect.

Some things, however, have not changed. You can't know what users will value until you build something. AI can't shorten that. Likewise, who makes decisions inside the company, and whether the frontline can accept a new way of working, have nothing to do with development speed.

What actually determines the length of MVP development is this human side. The distinction we want to make here is between time spent considering what things should be and time spent stalled waiting for confirmation. The former pays back in the quality of the deliverable; the latter produces nothing. On a project where implementation finishes in three weeks, spending two weeks on consideration is an investment. Being stalled for two months waiting in line for sign-off is not.

Precisely because AI has made implementation faster, the difference between these two now shows up directly in timeline and quality.

We describe this way of thinking as "AI expands, people compress." We have written more about it in Our Approach to AI Adoption and How We Proceed.

Common Failures in MVP Development

Having multiple hypotheses: If you want to test three things, you can't tell from the results what made the difference. If you can't narrow it to one, the business design itself may not be settled yet.

Setting the success criterion afterwards: If you create the criterion after release, the interpretation will be tailored to whatever numbers came out.

Ending with internal evaluation: Internal reactions are reference information. They are not a basis for decisions.

Building the MVP as the first version of a finished product: If you build it in a structure that can't be thrown away, the "cost of rebuilding" creeps into every decision about changing direction.

Launching without deciding on operations: Once real users are using it, inquiries will come in. If you haven't decided who handles them, things stall right after launch.

Leaving even the hypothesis design to the vendor: What to test is a business-side decision. If you hand this to an outside party, the scope will settle wherever is convenient for the building side. The building side doesn't have as much information as the ordering side about how the business will win.

Forgetting to build in measurement: This is the case where, after launch, you "feel it's being used but can't produce numbers." Once you have decided what counts as success, include a way to measure it in the scope.

Too many stakeholders: Narrowing the scope becomes harder the more participants there are. Each raises requests for their own area, and no one can make the call to cut. Things move once you designate one person to decide.

How to Choose an MVP Development Partner or Company

When you outsource MVP development, what matters is less the ability to build than whether they can narrow the scope with you. Here are points worth checking when comparing development companies.

• Whether, instead of estimating exactly what was requested, they ask back, "is that needed for this test?"
• Whether they can talk on the assumption that what is built may be thrown away depending on test results
• Whether they design with operations after launch, and later rebuilding, in mind
• Whether they have experience building and operating their own products. With only contract work behind them, their feel for what happens after launch tends to be weaker
• Whether they report test results in business terms: whether they can talk about what happened to the hypothesis, not just list the features they implemented
• Whether they can explain concretely how they use AI. A good indicator is whether they can separate what gets faster from what doesn't

As a business co-creation partner, we get involved from the PoC or MVP stage, narrowing down hypotheses together with clients. Our system development service, which covers everything from requirements definition through operations, and our AI implementation support, which supports AI adoption from the testing stage, follow the same thinking. We also publish our past case studies.

We have written in detail about how similar failures arise in the context of AI adoption in Common AI Adoption Failures and the Consultations We Actually Receive.

Frequently Asked Questions

How does MVP development differ from a PoC or agile development?

A PoC (trial implementation) tests whether something is technically feasible, while MVP development tests whether it works as a business. Who it is tested with also differs: a PoC is completed internally, but MVP development only works once real users use the product. Agile development is on a different axis altogether: it is about "how to build and proceed," not "what to test." MVP development is sometimes run with agile development.

What is the difference between an MVP and a prototype?

A prototype is a trial build for checking the look and the flow of operations internally, and it may not even work. An MVP is a product that real users use, built to a quality that delivers value.

How long does MVP development take?

If the scope is well narrowed, a few weeks to about three months is a rough guide. What companies publish also generally falls within this range. However, the main cause of a longer timeline is more often waiting time while specifications remain undecided than the amount of implementation, so whether you have narrowed down to one hypothesis to test largely determines the timeline.

How can we keep MVP development costs down?

Before cutting features, consider whether you can change how you build. If the hypothesis can be tested with an announcement page alone, people working manually behind the scenes, or a combination of existing tools, you can test it without spending on development. Even when you go into development, dropping features not needed for the test is the most effective measure.

Should we build an MVP in-house or outsource it?

If you have engineers in-house who can make decisions alongside the business side, building in-house is faster. Even if you outsource, keep the decision about what to test on the business side. If you hand that over too, the project may proceed with what you wanted to test drifting off course.

Can we ask a development company for MVP development only?

Yes. However, depending on the test results, rebuilding or cancellation is possible, so confirming first that the partner can share this assumption makes later decisions easier.

What are common failure patterns in MVP development?

Five are often seen: having multiple hypotheses to test, setting the success criterion afterwards, ending with internal evaluation, building in a structure that can't be thrown away, and forgetting to build in measurement. We cover them in detail in the "Common Failures in MVP Development" section above.

Can what we built as an MVP be used in production as is?

Sometimes yes, sometimes no. Because the purpose of MVP development is testing, preparations for growing user numbers and for how critical uptime is are often kept to a minimum. The usual approach is to decide which parts to rebuild after the test is passed.

Summary

MVP development is not a method for building cheaply and small. It is an approach where you narrow down to one hypothesis to test, and build only the parts needed for that test, at a quality that reaches users.

AI has made implementation faster. As a result, the judgment of narrowing the scope carries more weight. Precisely because you can build almost anything, deciding what not to build is more effective than before.

If you are unsure how to take the first step in a new business, please reach out via our contact page. We will work with you, starting from sorting out what you should test.