The PoC Perspective — Organizations That Never Finish, Individuals Who Move Forward

1. What Is PoC

Proof of Concept. The act of testing on a small scale whether a given technology or idea is feasible.

A proper PoC has a clear structure.

• Hypothesis — "Can this technology solve this problem?"
• Verification — Build it and test
• Verdict — It worked / It didn't
• Decision — Proceed / Stop / Change direction

When these four steps complete their cycle, a PoC ends in days to weeks. The problem is that in far too many cases, this cycle never completes.

2. The PoC That Never Ends

A common scene in large enterprise IT departments.

"We ran a PoC. Results were promising. As a next step, we're planning a larger-scale PoC."

This is not PoC. It is indefinite postponement wearing the name of PoC.

Organizations where PoC never ends share common patterns.

• Ambiguous success criteria — what constitutes "success" was never defined upfront. So even when results arrive, no verdict can be reached
• No tolerance for failure — concluding "it didn't work" creates accountability issues. So no conclusion is drawn
• No decision-maker — there is no one who can say "go" or "stop" based on results. So "more verification is needed" becomes the default
• PoC as its own purpose — "we're experimenting with new technology" is reported as an achievement. Conclusions are not expected

The purpose of PoC is not "to try."
It is "to decide."

3. TokiStorage's PoC — Opus Fails, Codec2 Emerges

TokiStorage's voice QR code began with one clear PoC.

Hypothesis: Can a human voice fit in a single QR code (maximum 2,953 bytes)?

PoC 1: Opus

The first attempt used Opus — a web-standard audio codec with native browser decoding. In theory, reducing the bitrate to 1–2 kbps should fit tens of seconds of audio into a QR code.

The result was unambiguous. Opus at 2 kbps and below falls into DTX (Discontinuous Transmission), outputting essentially silent frames. At 4 kbps and above, entropy is too high for compression to help — only 2–3 seconds fit in a QR. Between 2–4 kbps, no usable middle ground existed.

Verdict: Opus cannot solve this.

PoC 2: Codec2

Next came Codec2 — an ultra-low-bitrate voice codec designed for amateur radio that maintains intelligible human speech even at the extreme low of 450 bps.

Result: at the 450 bps mode, approximately 29 seconds of voice fit in a single QR code. The quality is robotic, but speaker identity is recognizable and content is intelligible.

Verdict: Codec2 solves this.

The entire PoC took days. There was a hypothesis, verification, a verdict, and a decision. Because the conclusion that Opus "couldn't do it" was accepted, Codec2 was reached.

"It didn't work" is not failure.
It is the entrance to the next hypothesis.

4. When PoC Becomes Architecture

TokiStorage's PoC has one distinguishing feature: the PoC artifacts became part of the product itself.

In many organizations, PoC and product development are disconnected. PoC is done by a "technical validation team," whose findings are handed to a "product team" that redesigns from scratch. Half the insights from the PoC are lost in this handoff.

In TokiStorage, one person carries through from PoC to product, so PoC judgments directly become architectural design principles. Zero information loss.

5. The Art of Stopping

The most important function of PoC is enabling the decision to stop.

When it became clear that Opus could not achieve voice QR, investment in Opus was cut immediately. The option to keep searching the 2–4 kbps middle ground for optimizations existed, but the PoC verdict was clear. Structurally impossible.

Many organizations cannot make this "stop" decision. To justify already-invested time and budget, they continue: "with a little more optimization," "if we adjust the parameters." This is the sunk cost trap, and it is the true identity of the never-ending PoC.

The value of PoC lies not only in "it worked." Its greatest value is in establishing "it can't" early.

6. PoC Should Be Minimal

A good PoC is small. One hypothesis, one verification, one verdict.

"Can voice fit in a QR?" is one hypothesis. "Can Opus do it?" is one verification. "Opus can't" is one verdict. From there, the next hypothesis — "What about Codec2?" — is born.

One reason enterprise PoCs never end is that their scope is too large. "Can AI be applied to our business?" is not a hypothesis — it's a wish. "Can GPT-4 classify this field in this form?" is a hypothesis.

The smaller the hypothesis, the faster the verification, the clearer the verdict, and the easier the decision.

7. Conclusion — PoC Is a Tool for Decisions

TokiStorage's voice QR code began with Opus's failure. Accepting "it didn't work" led to Codec2. Codec2 working confirmed the architecture. A confirmed architecture is why the structure stands firm today.

PoC is not a technology demonstration. It is a decision-making tool. Define criteria beforehand, accept results, and move forward. That cycle, repeated, builds structure that isn't a facade.

The question is always the same. Are you prepared to accept the PoC's results?

Related Essays

• SSDLC — When Security Becomes Ethics
• Enterprise Architecture — The Irreversible Choice of Initial Design
• The Decision-Maker's Resolution — Organizations That Cannot Decide, Individuals Who Inscribe Their Names