MVP and PoC Development

It depends on which side holds the biggest uncertainty right now. If the technical uncertainty is large, such as whether AI can read handwritten slips or whether data can be extracted from your existing core business system, start with a PoC (proof of concept). If the technology is not in question and what you do not know is whether it can work as a business at all, start with an MVP (minimum viable product). You do not need to do all three, one after another.

A prototype is a trial build for internal stakeholders to check the look of the product and the flow of use, and it may not actually work. An MVP (minimum viable product) is a product that real users use, built to a quality at which its value reaches them. Put very briefly, a PoC (proof of concept) tests “can it be built,” a prototype tests “can it be used,” and an MVP tests “will it be used.”

If the scope has been narrowed down, several weeks to about 3 months is one rough guide. The breakdown is 1–2 weeks to decide on one hypothesis, 1–2 weeks to select the scope, several weeks to 3 months to build, 2–4 weeks to put it in users’ hands, and about 1 week to make the decision. The main thing that stretches the schedule is not the amount of implementation but the waiting time while specifications remain undecided. From the start, we work with you to set up a structure in which you see a working product at least once a week and can decide on the spot.

Because the cost varies greatly depending on how the scope is set, we do not quote an amount up front. The number of screens, the types of users, integration with external systems, whether existing data needs to be migrated, the devices to support, and who handles operations after launch: we go through these six points with you before preparing an estimate. There is no charge at the consultation stage.

It is because the scope that the word “MVP” (minimum viable product) refers to differs from company to company. Even in publicly available information, the same “no-code MVP development” is listed at ¥100,000 in some articles and ¥5,000,000 in others. It is not that one of them is wrong; the scope they include is different. When comparing, you can judge them properly if you align the assumptions on the six points above before looking at the amounts.

Yes, you can. We take on the technical decisions. However, the decision about what to validate stays with the business side. If you leave even that to us, the project may move forward while drifting away from what you wanted to confirm. We work with you on the premise that you take part in the sessions where the hypothesis is decided.

Yes, you can. In that case, we start by listing the features in the document and checking, one by one, “Would we be unable to validate the hypothesis without this?” A requirements definition document is often a collection of stakeholders’ requests, and it is usually larger than the scope needed for validation.

In some cases it can be used as is, and in others it needs to be rebuilt. Because an MVP (minimum viable product) exists for validation, preparation for user growth and for how little downtime can be tolerated is often kept to a minimum. We build in a way that lets you change direction, and for parts that remain usable after a change of direction, such as authentication and data storage, we use existing mechanisms. After the MVP passes validation, we work with you through the design of what to keep and what to rebuild.

Yes, we can. However, each additional system to integrate with adds specification checks and exception handling. Please let us confirm together, at the stage where the scope is decided, whether that integration is truly needed for the hypothesis you want to validate. At the validation stage, we sometimes substitute manual work for the integration and then build the integration ahead of production.

Yes, you can. However, the stage where we add the most value is deciding together what to validate. We also accept requests for implementation only, with the specifications already fixed, but in that case we would be “building what we are told” and cannot fulfill the role of narrowing the scope. Please tell us which approach you would prefer.

We handle web applications, smartphone apps, SaaS for external customers, and internal business systems. We also design the embedding of AI features based on what we have learned from the production operations of AI in our own products. At the validation stage, we sometimes propose testing on the web first and building the app only once it becomes necessary.

Yes, we can. We are set up to handle everything from requirements definition through design, development, and post-launch operations. Rebuilding after validation can also continue directly with the same team. We provide the scope of maintenance and how spec changes are handled in writing at the time of the estimate.

Yes, that is fine. In fact, the goal is to be able to make that decision early. That is why we keep the initial investment small. Even when you continue, we decide what to validate next before moving forward. If you move on to detailed build-out without deciding this, everything after that ends up as development without a hypothesis.