System Development PoC: Costs (¥100K–¥3M) and How to Succeed

A PoC (Proof of Concept) is a small trial run carried out before full system development to check whether an idea is technically feasible and whether it will deliver the expected benefit. Instead of building the finished product, you test only the most uncertain part, quickly and on a small budget, and use the result to decide whether to proceed, change course, or stop.

If you order a system costing millions or tens of millions of yen and only then discover it is not what you imagined, or that the AI is not accurate enough, it is very hard to recover. The idea behind a PoC is to reduce that uncertainty first, for a fraction of the cost. This article is written for executives and non-IT staff at small and mid-sized companies. It covers the differences between a PoC, a prototype and an MVP, when a PoC makes sense and when it does not, typical costs and durations, how to set pass criteria, contract points to check, common failures, and a pre-order checklist. All figures are general market ranges; actual amounts vary widely with scope and vendor.

A common misunderstanding is to treat a PoC as a scaled-down version of the final system. Its purpose is not to produce something polished but to test a hypothesis and gain information for a decision. If you want to know whether AI can sort incoming inquiry emails automatically, you do not need screens or a login function. You can measure the classification accuracy on a few hundred past emails. If you want to know whether staff can handle a new input screen, you do not need back-end processing. A screen that moves, which people can actually try, is enough.

So the first step is to decide what is most uncertain, and to test only that. Uncertainty comes in three broad kinds: can it be built (technical risk), will people use it (adoption risk), and will it produce a benefit worth the cost (value risk). If you start a PoC without knowing which of these you are trying to remove, you tend to end up with something that works but with no clear idea of what you learned.

Two similar terms are prototype and MVP (Minimum Viable Product). They are often mixed up in practice, so before ordering, make sure everyone agrees on which one you actually want.

In short, a PoC asks whether it can be done, a prototype lets you see and touch it before deciding, and an MVP puts a small version out to see how people respond. For a new ordering system, for example, you might first align with staff using a screen mock-up (prototype), run a PoC if the automatic integration looks risky, and then start operating with a minimal set of functions (MVP). You do not have to go through every step; skip those where uncertainty is already low.

A PoC is not a cure-all. Doing one does not guarantee safety, and not every project needs one. Two questions help you decide: how large is the loss if the project fails, and are there parts that you cannot know without trying?

A PoC is a good fit in cases like these.

- Projects that use AI or machine learning (the accuracy you can reach is unknown until you test with your own data)
- Projects involving integration with existing systems or external services, where it is uncertain whether they will connect
- New operations or services with no precedent, where it is unclear whether staff will adopt them
- Projects with a large full-development budget (as a rough guide, several million yen or more)
- Projects where executives, front-line staff and developers do not share the same picture of the end result
- Projects where you need to show something working to win internal agreement

On the other hand, a PoC is unnecessary, or a light version will do, in cases like these.

- Standard packages or SaaS products with a track record (a trial period or demo is enough to check)
- Small modifications to an existing system where the specification is clear
- Work of a kind that you or your vendor have done many times, so technical uncertainty is small
- Small budgets where the PoC would cost nearly as much as the real build
- Projects where the decision is already made and the PoC would be a formality

The last case deserves attention. If you will proceed to full development whatever the result, the PoC becomes just a prepaid phase and loses its value as decision material. What matters is whether you are genuinely prepared to cancel or change direction if a certain result comes out. For the overall ordering process, see the system development ordering guide.

PoC costs vary greatly depending on what you verify. The following are general market ranges, not the prices of any specific company and not guarantees. Depending on data readiness, scope and the size of the vendor, actual amounts can fall outside these ranges.

AI accuracy checks tend to cost more because preparing and processing data and creating correct answers for evaluation takes effort. If you organize the data yourself in advance, you can reduce both cost and time. As a rule of thumb, a PoC is kept to about 10 to 20 percent of the full-development cost: around ¥300K for a ¥3M project, or ¥1.5M to ¥3M for a ¥30M project. If the PoC alone approaches the cost of the real build, it is worth checking whether the scope has grown too large. For the cost of full development, see the system development cost guide.

As for duration, longer is not better. Beyond three months the purpose tends to blur and the PoC turns into early development. Agree on a time limit up front and promise to hold a decision meeting when it arrives, whatever the result. That prevents the work from dragging on.

The most important thing in a PoC is to decide, in numbers and before starting, what counts as success. Without that, opinions drift once results arrive, with remarks like it looks reasonably good or it might improve with a bit more time, and you end up unable to decide. A three-part set makes this easier to organize.

- Metric: what to measure (for example classification accuracy, processing time per item, number of input errors, staff satisfaction)
- Pass line: what value counts as a pass (for example accuracy of 90% or higher, processing time at half the current level or less)
- Decision rule: what to do on pass, fail, or in between (for example, pass leads to a full-development quote; in between means narrowing the scope and re-testing; fail means stopping)

The trick is to base the pass line on current operations. If people classify inquiries today with 95 percent accuracy, the bar for AI may not be 95 percent or more; it may be the level at which, with a human check, the work time is cut in half. Aiming for perfection produces a PoC that never passes. Decide together with front-line staff the minimum level at which they would say, yes, we can use this.

It is also important to expect a fail. The value of a PoC is not in succeeding but in reaching a correct decision early and cheaply. A PoC that ends in failure has prevented a multi-million-yen mistake at a fraction of the cost, which is a real result. Sharing this view with executives and stakeholders in advance changes how the outcome is received.

Because a PoC contains elements that cannot be known without trying, the way you think about the contract differs from ordinary development. Here are the points to confirm. The basics of development contracts are also covered in development contract basics.

The prevalence of quasi-mandate contracts may feel unsettling for the client. But a PoC tests the very thing that is uncertain, so a guaranteed result does not fit its nature. Instead, you can build confidence by fixing the process in the contract: how the verification is carried out, how often progress is reported, and when the decision meeting takes place.

Another point that is easy to overlook is the transition to full development. Some vendors take on a PoC at a low price on the assumption that they will also win the full build. That is not wrong in itself, but if you cannot receive the PoC deliverables (source code and verification data) and cannot switch vendors, you lose bargaining power on the full-development price. It is safer to make sure you receive the deliverables and can compare the full-development quote with others. For comparing proposals, the basics of an RFP is also useful.

A situation where a PoC succeeds but never leads to full development is sometimes called PoC death or PoC purgatory, and it is a widespread problem in AI and digital transformation projects. The project passed technically and was then forgotten. In most cases the cause lies not in the result but in how the PoC was started.

- It started with let's just try it, before the full-development budget or owner was decided
- The means came first (we want to use AI) rather than a real problem on the front line
- Nobody had decided who would do what on a pass (who leads full development, who approves the budget)
- Only the technology was tested; operating effort, security and fit with existing work were not considered
- Only the PoC owner was enthusiastic, with no involvement from front-line staff or executives

The remedy is simple: before starting, decide what happens if it passes, meaning by when, who, with what budget, and doing what. It need not be final, but an outline such as if it passes, we will get a full-development quote in next year's budget, with named approver and front-line lead, should be set before the PoC begins. Letting front-line staff try the result during the PoC and gathering their feedback on real operation also makes the move to full development smoother. For more on AI adoption pitfalls, see AI adoption failure patterns.

Here are typical ways the PoC itself fails, separate from the PoC purgatory described above. They tend to arise from how the verification is run.

Testing only on clean data is especially easy to miss. A high accuracy on tidy sample data that drops sharply on real data full of spelling variations and missing values is a story heard often. Using data as close to real work as possible, including cases that do not go well, is what makes a PoC meaningful. For failures common across development as a whole, see system development failure patterns.

Here is the typical flow. Even for a small PoC, following this order improves the quality of the outcome. First, organize the problem and hypothesis: be able to state in one sentence the business problem you want to solve and the hypothesis that this approach will solve it. Second, set the success criteria: the metric, pass line and decision rule described above. Third, fix the scope and data: what will be built and not built, which data will be used, and who will provide and process it. Fourth, carry out the verification in a short period, sharing status weekly and adjusting within the scope if a course correction is needed. Fifth, report the results and hold a decision meeting: summarize not only the numbers but what was learned, what remains unknown and recommendations for full development, then decide the next step following the rule set beforehand.

It is important that the person with decision authority attends the decision meeting. If it ends with a report at staff level, that becomes a cause of PoC purgatory. Booking the meeting date at the start of the PoC also helps.

Before requesting a PoC, check the following items. You do not need to answer yes to all of them, but any item you cannot answer is likely to cause trouble later.

- I can explain the business problem to be solved in one sentence
- I have decided which uncertainty to test (technical, adoption or value)
- I have decided the metric and the numerical pass line
- I have decided what to do on a fail or an in-between result
- The PoC cost is a reasonable share of the full-development cost (roughly 10 to 20 percent)
- I have set the duration, the decision meeting date and the attendance of the decision-maker
- I have decided which real data will be used and who provides and processes it
- I have confirmed the contract type (quasi-mandate or contract for work) and the scope in writing
- I have confirmed the deliverables, ownership of intellectual property and data handling
- I have confirmed that there is no obligation to place full development with the same vendor and that I can switch
- I have outlined the budget, owner and schedule for after a pass
- Front-line staff are part of the verification team