Most system-development failures are decided not by technology but by “the assessment before building.” You firm up requirements completely, sign a large contract, and a year later the finished product doesn’t fit the work—the way to avoid this structural failure is the “build small and confirm” approach using a PoC (proof of concept) or MVP (minimum viable product).
The difference between PoC and MVP
- PoC (Proof of Concept) — A prototype to confirm “whether it’s technically feasible” and “whether that method produces results.” Used only by a limited group inside the company.
- MVP (Minimum Viable Product) — A minimal product to confirm “whether real users will use it.” You have actual users use it.
What both share is that the purpose is not “to build” but “to obtain material for a decision.”
Cases where you should build small, and cases where you shouldn’t
Cases it suits
- Using technology like AI or automation whose accuracy you can’t know without trying
- No precedent within the company, and requirements can’t be fully firmed up in text
- Persuasive material is needed for an investment decision (a management meeting or approval process)
- There are multiple approaches and you can’t decide which fits the field
Cases it doesn’t suit
- Routine systems with clear requirements and plenty of precedent (attendance, expense reimbursement, etc.)—adopting an off-the-shelf SaaS comes first
- Things with no choice about “whether to do it,” such as legal compliance
How to run a PoC (2–4 weeks as a guide)
- Narrow to one hypothesis you want to confirm — Be concrete, like “how far can AI automate the sorting of invoices.” If you have three hypotheses, split the PoC into three.
- Decide the measure of success first — Put a criterion you can judge by when it’s done—“90%+ accuracy,” “halve the processing time”—in writing.
- Test with real data — A demo on sample data isn’t hypothesis testing. Confirm with real data and real operations.
- Decide “proceed, change, or stop” — A PoC that reached a “stop” decision isn’t a failure; it’s a success that avoided a multi-million-yen loss for a few hundred thousand yen.
To avoid “PoC poverty”
On the other hand, there’s a failure pattern called “PoC poverty,” where you just keep repeating PoCs and never advance to production. The cause is almost always the same: not deciding the conditions for moving to full development at the outset. If, when starting the PoC, you decide as far as “if it meets this criterion, we’ll apply for the full-development budget,” the PoC functions as a tool for decisions.
Points to note when commissioning
- Confirm the rights to the PoC’s deliverables — Whether the contract leaves the source code and validation data with your company.
- Have the rough estimate for full development produced at the PoC’s end — An estimate informed by the PoC’s results is in a different league of accuracy.
- Have the throwaway-by-design parts spelled out — Because a PoC is built speed-first, it’s healthy for there to be parts you rebuild in full development. A vendor that shows this from the start is trustworthy.
Summary｜Before the big contract, a small validation
SHANNON’s rapid PoC and prototype validation is a service that delivers “something that works” and “material for a decision” in 2–4 weeks. It also covers validating the business use of generative AI. If you proceed to full development, the same team continues to handle design, implementation, and operation, so nothing you learned in validation goes to waste.