A blockchain proof of concept (POC) is a small, time-boxed build that tests one risky assumption, such as "can three companies share settlement data on a ledger without exposing prices to each other". It is not a demo for investors and not a first version of the product. A good POC ends with a clear yes, no or "not like this".
POC, prototype and MVP are different things
| Proof of concept | Prototype | MVP | |
|---|---|---|---|
| Question it answers | Is this technically and organizationally feasible? | What should it look and feel like? | Will real users adopt and pay? |
| Audience | Internal team, consortium partners | Users, stakeholders | Real customers |
| Code quality | Throwaway is fine | Mostly throwaway | Production-grade, audited |
| Typical length | 3–8 weeks | 2–6 weeks | 3–6+ months |
Mixing them is the most common way POCs fail. A team builds a pretty interface on mocked data, everyone applauds, and the hard question about privacy or throughput is still open.
Choosing the right question
Start by writing the riskiest assumption in one sentence. Typical blockchain POC questions:
- Can partners agree on a shared data model and governance, and will they each run a node?
- Can the privacy model (channels, private transactions, hash anchoring) keep commercial data confidential?
- Does the chosen network handle peak transaction volume at acceptable cost and latency?
- Can the ledger integrate with the ERP or core system that holds the source data?
- Will users tolerate the wallet and signing flow?
Then write success criteria that are measurable before you start: "settles 500 transactions per minute with under five seconds to finality on a three-node network", or "two partners complete an end-to-end reconciliation without emailing spreadsheets".
What to build and what to fake
Build the part that carries the risk properly; fake everything else. If the question is about privacy, implement real privacy groups and real key separation, but use a hardcoded user list instead of single sign-on. If the question is about performance, use a realistic network topology and load generator, but skip the dashboard. Common things safe to fake in a POC: authentication, polished UI, admin tools, production monitoring, and most error handling.
A typical POC plan
- Week 1: frame. Assumption, success criteria, participants, data model sketch, platform shortlist.
- Week 1–2: choose the stack. For consortium questions, usually Hyperledger Besu or Fabric (see private blockchain development); for public-chain products, a testnet of the target chain.
- Weeks 2–5: build the critical path. Contracts or chaincode, one integration, a script or minimal UI to drive it. Use established libraries; see smart contract development for tooling.
- Weeks 5–6: measure. Run the scenario against the success criteria. Record numbers, not impressions.
- Week 6–8: decide. Write a short report: what worked, what did not, what production would require, and an honest cost estimate for the next stage.
Cost drivers
A POC is mostly people-time. A typical team is one or two engineers, part of an architect's time and a product owner from the business side, for four to eight weeks. Multiply that by your loaded rates to get a realistic budget. Costs rise with the number of organizations involved, because every extra partner adds meetings, security reviews and integration points. Cloud and testnet costs are usually trivial in comparison.
Red flags
- No written success criteria, or criteria that cannot fail.
- A vendor proposing their own proprietary chain for a POC you will later need to run yourselves.
- Partners "observing" rather than running nodes or providing real data.
- Production-style features in scope, such as token sales, mobile apps or full KYC, before the core assumption is tested.
- Nobody has asked whether a shared database would solve the problem.
After the POC
If the answer is yes, expect to rebuild. POC code skips the security, testing and operational work production needs, including an external smart contract audit for anything holding value. If the answer is no, that is a successful POC: you avoided a much larger failed project. An independent review from a blockchain consulting engagement can help when internal teams disagree on the result.
Frequently asked questions
How long should a blockchain POC take?
Usually three to eight weeks. Longer than that and it is turning into an MVP without the discipline of one. Multi-company POCs take longer mostly because of coordination, not code.
Should a POC run on mainnet?
No. Use a public testnet or a local or private network. Mainnet adds real costs and risks without answering any feasibility question you could not answer on a testnet.
Can POC code be reused in production?
Ideas, data models and some integration code often carry over. Smart contracts and security-sensitive code should be rewritten with full tests and audits. Plan for that from the start so nobody is surprised.
What should the final POC report include?
The original assumption, the success criteria, measured results, what was faked, known risks, a recommendation and a rough plan and budget for the next stage, or the reasons to stop.