What Is a PoC?

Tomohiro Iida · Published April 7, 2026 · Updated July 12, 2026

A PoC, or proof of concept, is a small-scale check of whether a new technology or new business idea is technically and commercially workable before committing to full-scale investment. The point is not to build a working demo for its own sake; it is to get material for deciding whether to move forward, stop, or rebuild.

What a PoC is: definition, and how it differs from an MVP or prototype

A PoC (proof of concept) is a limited-scope check of whether a new technology, service, or process actually works, not just in theory, before development ramps up fully. The goal is to confirm feasibility and get grounds for an investment decision ahead of full commitment.

What matters is that a PoC is not about building a product; it is positioned as gathering evidence for a decision. Building something that runs is not, on its own, the goal.

PoC (Proof of Concept)

Validates whether a technology or business concept is feasible. Speed of validation is prioritized over how finished the result looks.

Prototype

A trial build to confirm the UI, UX, and feel of a product. Weighted more toward sharing a visual sense of the finished product.

MVP (Minimum Viable Product)

A minimal product that can actually be handed to real users. This is the stage for getting market feedback.

• When it is unclear whether a new technology, such as blockchain or DID, can be applied to your operations
• When you need to confirm whether integration with an external API or a third-party service is workable
• When it is unclear whether performance or scalability will meet requirements
• When leadership or investors need a working demo as material for a business-case decision

How to run a PoC: 5 steps

A PoC follows broadly the same structure regardless of industry or scale. The five steps below form the basic framework; skipping a step tends to raise rework cost later.

Step 1: Frame the problem

Clarify what is being validated. List out the questions that need an answer, whatever is technically uncertain, business assumptions, and the basis for a cost estimate, to identify which ones need to be resolved for a go-ahead. Leaving these points vague at this stage causes rework later.

Step 2: Design the hypothesis

Turn the problem into a testable hypothesis, framed as "if X, then Y should hold," and define an evaluation metric (KPI) for each hypothesis that can be judged true or false. Do not rely only on qualitative judgment; set at least one metric that can be measured numerically.

Step 3: Plan the validation

Decide the duration, scope, and stack. Start small as a rule, full production-level functionality is not needed, and keep implementation to the minimum required to test the hypothesis. Document the Go criteria at the same time (for example, latency under 300ms, user satisfaction of 4.0 or higher).

Step 4: Execute

Carry out implementation, testing, and data collection according to plan. Because scope tends to expand mid-way, set a rule that additional requests go into a backlog as "discuss after the PoC." Share progress with the steering committee weekly, and revise the hypothesis immediately if an assumption changes.

Step 5: Decide (Go / No-Go / Pivot)

The final deliverable of a PoC is a decision document, not a working demo. State the result, the basis for it, and the next action for each hypothesis tested. Treat a Go decision as input to production design, and treat a No-Go decision positively, as a call that minimizes the cost of walking away.

Netsujo runs a "success-definition workshop" before a PoC starts, to put a Go-signal criterion in writing that every stakeholder agrees on. Spending a day or two on this step tends to reduce mid-course direction changes during validation.

Typical PoC costs by scale

PoC cost varies substantially with scale, duration, and scope. The figures below are rough guides by scale when using outside support; they will move with in-house engineering hours and how much existing infrastructure can be reused.

• Technical complexity: specialist domains such as blockchain, AI, and DID raise design cost
• Number of external integrations: more connection points with existing core systems or APIs means more effort
• Regulatory and legal work: regulated sectors such as finance, healthcare, and government add legal-review cost
• Documentation requirements: higher expectations for decision documents and reports raise project-management cost

Three patterns behind PoC failure

Where a PoC "validates fine but never reaches production," the cause is more often organizational or process-related than technical. Three typical patterns follow.

Success criteria stay vague

Starting from "as long as it works, that's fine" leaves no answer to "does this mean we can go to production?" once the PoC ends. A numeric criterion for "what needs to be confirmed to move to the next phase" needs to be written down before the PoC begins.

Production-rollout design gets left for later

Many cases where a PoC succeeds but production rollout fails trace back to scalability, security, and operating cost not being considered during the PoC. To avoid a situation where "it worked in the PoC but the design cannot handle production," work out the production requirements at PoC design time.

Stakeholders are not sufficiently involved

A PoC run solely by the technical department, without the business side, legal, or leadership involved, tends to stall at production for reasons such as "approval will not come through" or "the business value never got across." Involving decision-makers in the validation process and requiring interim reporting lightens the approval process once the PoC ends.

What these three patterns share is that "building the PoC" became the goal in itself. A PoC is a means toward production and toward becoming a business; it is not the deliverable. When that understanding is not shared among stakeholders, one of these patterns tends to follow.

Three points for PoC success

The reverse of the failure patterns is not automatically a recipe for success. To make a PoC function as an investment toward production, three points matter in particular.

Set withdrawal criteria first

Agree on a No-Go criterion before agreeing on a Go criterion. Having a line such as "we stop if this KPI falls below X" in place ahead of time prevents an emotional decision to keep going and keeps losses down. Withdrawing is not failure; it is redirecting resources appropriately.

Break the PoC into small cycles

Running three two-week PoCs tends to produce more learning than one three-month PoC. Update the hypothesis each cycle to sharpen validation accuracy. The earlier a problem surfaces, the lower the cost of fixing it.

Design backward from the exit

Design the PoC by working back from what production looks like afterward: which stack production will run on, which team will maintain it, and what cost model will apply. Those answers become constraints on the PoC design. Without this backward design, technology gets chosen for the PoC alone, and production-migration cost balloons.

A smart contract is costly to modify and redeploy once live. Validating contract design thoroughly, even at PoC stage, is key to keeping production-migration cost down. On an EVM-compatible chain, a testnet allows production-equivalent validation, which helps control PoC cost while confirming technical feasibility, though production-chain-specific fees, congestion, and latency still need separate confirmation. A PoC involving token issuance or transfers needs an upfront check on whether the Financial Instruments and Exchange Act or the Payment Services Act applies, with legal cost budgeted in from the start. A local-government or public-sector Web3 PoC, such as regional digital currency or DID infrastructure, brings additional considerations beyond a private-sector project, including procurement rules, personal-data protection ordinances, and building resident consensus.

Frequently asked questions

How is a PoC different from an MVP or a prototype?

A PoC validates whether a technical or business concept is feasible; a prototype is a trial build to confirm UI, UX, or feel; an MVP is a minimal product delivered to real users to get market feedback. A PoC's goal is not a finished product, but material for deciding whether to move to production.

How is PoC cost decided?

PoC cost is set by three things: validation scope (what is being confirmed), duration, and team structure (in-house or outside support). It also moves with technical complexity, the number of external-system integrations, and whether the sector is regulated. Netsujo publishes a fixed-price Web3 PoC design package (JPY 800,000, excluding tax, over 4 weeks) with cost and delivery date agreed before work starts, and larger custom-development validation is quoted from a range (concept and requirements definition, JPY 500,000-2,000,000; PoC and prototype, JPY 2,000,000-8,000,000). Working out the hypothesis and success criteria first, then estimating for the smallest scope needed, is the recommended starting point.

How long does a PoC typically take?

There is no single right answer, but roughly 4-12 weeks, enough to complete the validation needed for a decision, is our operational rule of thumb. Running several two-week validations in sequence can produce more learning than one three-month PoC. Duration depends on validation scope and team structure, so narrowing scope before starting matters.

What does it take to make a PoC lead to production, rather than stopping there?

Whether a PoC can move to production depends not only on whether it worked technically, but on whether commercial viability, operating structure, security and legal compliance, and scalability were assessed during the PoC. Leaving scalability and security for later risks a state where "it worked in the PoC but cannot handle production." Working out production requirements from the PoC design stage helps.

Can we ask for PoC design only, and handle production development in-house or with a different company?

Yes. It is workable to have PoC design and validation handled externally, then move to in-house or a different partner for production development once a Go decision is made. In that case, designing the PoC with the intended production stack in mind helps keep migration cost down. We can also help work out how the roles split.

Summary

A PoC is a process for gathering grounds for a decision, not a process for building something that runs. Losing sight of that distinction tends to produce validation that works technically but never connects to business value.

The basic process is five steps: frame the problem, design the hypothesis, plan the validation, execute, and decide. Making the deliverable of each step explicit prevents misalignment among stakeholders.

As a rough guide, cost runs from several hundred thousand yen for Small, several million yen for Standard, and JPY 10,000,000 or more for Enterprise, though technical complexity, external integrations, and regulatory requirements can move that range considerably.

Most failures trace back to one of three things: vague success criteria, production design left for later, or missing stakeholders. The keys to success are agreeing on withdrawal criteria upfront, validating in small cycles, and designing backward from the exit.