Blockchain proof of concept: how to scope and run one

A blockchain proof of concept (POC) is a small build with a fixed end date that tests one risky assumption. This guide covers how to choose that assumption, what to build or fake, how long a POC takes and how to read the result.

A typical assumption sounds like this: "Three companies can share settlement data on a ledger without showing their prices to each other." A POC is not an investor demo, and it is not the first version of the product. A useful POC ends with a clear yes, a clear no, or "not in this form".

Blockchain POC vs prototype vs MVP

The three terms describe different projects with different questions.

POCs often fail because a team mixes these goals. The team builds a polished interface on fake data, the audience likes the demo, and the hard question about privacy or throughput stays unanswered.

Choosing the question

Write the riskiest assumption in one sentence before any code is written. Common questions for a proof of concept blockchain project:

• Can the partners agree on a shared data model and governance, and will each partner run a node?
• Can the privacy design keep commercial data confidential? Fabric channels, private data collections and on-chain hashes are the usual options.
• Can the chosen network handle peak transaction volume at an acceptable cost and delay?
• Can the ledger connect to the ERP or core system that holds the source data?
• Will users accept the wallet and the steps needed to sign a transaction?

Then write success criteria that can be measured and that can fail. Two examples:

• "The three-node network settles 500 transactions per minute, and each transaction is final within five seconds."
• "Two partners complete a full reconciliation on the ledger without emailing spreadsheets."

What to build and what to fake

Build the part that carries the risk with real components, and fake the rest.

• If the question is about privacy, use real private data handling and separate keys per organization, while a hardcoded user list can replace single sign-on.
• If the question is about performance, use a realistic network layout and a load generator, and skip the dashboard.
• If the question is about integration, connect to a copy of the real ERP data, while a script can replace the user interface.

Most POCs can safely fake authentication, a polished interface, admin tools, production monitoring and most error handling.

Where to run a blockchain proof of concept

A POC should not run on a public mainnet, because mainnet adds real fees and real risk and a testnet answers the same feasibility questions.

A typical POC plan

1. Week 1: frame the question. Write the assumption and success criteria, name the participants, sketch the data model and shortlist platforms.
2. Weeks 1 to 2: choose the stack. Consortium questions usually go to Besu or Fabric, as described in the guide to private blockchain development. Public-chain products go to a testnet of the target chain.
3. Weeks 2 to 5: build the critical path. Write the contracts or chaincode, one integration, and a script or simple interface to drive them. Use established libraries such as OpenZeppelin. The guide to smart contract development covers current tooling.
4. Weeks 5 to 6: measure. Run the scenario against the success criteria and record numbers, not impressions.
5. Weeks 6 to 8: decide. Write a short report that says what worked, what failed, what production would need, and what the next stage would cost.

Cost drivers

Most of the cost of a POC is staff time: a typical team of one or two engineers, part of an architect's time and a product owner from the business side works for four to eight weeks. Multiply the hours by your full hourly staff cost, or by a vendor's day rate, to get the budget.

Costs rise with the number of organizations involved, because every extra partner adds meetings, security reviews and integration points. Cloud servers and testnet use cost little by comparison.

Lessons from projects that went past the POC stage

Two well-documented projects show that technical feasibility is only one of the risks.

• The Australian Securities Exchange cancelled its blockchain-based replacement for the CHESS settlement system in November 2022. The ASX wrote off between A$245 million and A$255 million before tax, after an independent review by Accenture.
• Maersk and IBM announced in 2022 that they would shut down TradeLens, a blockchain platform for shipping documents. Maersk said the platform had not become a viable business. The service went offline in early 2023.

For TradeLens, industry adoption was the open question, and a POC that tests partner commitment, and not only throughput, answers that question earlier and at lower cost.

Red flags in a POC proposal

• The proposal has no written success criteria, or its criteria cannot fail.
• A vendor proposes its own private chain, which you would later need to run yourselves.
• Partners only watch and do not run nodes or supply real data.
• Production features such as token sales, mobile apps or full KYC are in scope 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, plan to rebuild, because POC code skips the security, testing and operations work that production needs. Any contract that holds value also needs an external smart contract audit.

If the answer is no, the POC has still done its job, because it stopped a much larger project that would have failed. When internal teams disagree on the result, an independent review through a blockchain consulting engagement gives an outside view.

Frequently asked questions