Does Your Project Actually Need Web3?
Tomohiro Iida ·
"Should we adopt Web3?" is one of the most common questions we're asked. The short answer: in most cases, existing technology is enough. Web3 is only necessary when specific conditions are met.
When Web3 is worth it, and when existing technology is enough
Before deciding whether to adopt Web3, it helps to first sort cases into "needs it" and "doesn't need it." This split is the starting point for the decision.
| Category | Cases |
|---|---|
| Web3 is a good fit when | Tamper-resistance is a legal or business requirement; data must be shared across multiple independent organizations; proof of ownership of a digital asset is required; incentives need to be designed without a central administrator; automatic execution via smart contracts is required. |
| Existing technology is enough when | It's an internal system for a single company or organization; real-time processing or high-speed response is essential; a relational database plus access control satisfies the requirements; cost and development speed are the priority; end users are unfamiliar with operating a crypto wallet. |
Web3 and blockchain are not a technology that solves everything. Choosing the right technology for the right problem is the first condition for a project to succeed. Weigh cost, development speed, and operational complexity, and compare against existing technology before deciding.
Five criteria for deciding on adoption
These five points are comparison axes for different uses, not mandatory conditions that must all be met. A shared ledger may need neither asset transfers nor a token. Identify the requirement and explain the difference from existing technology before considering adoption.
- 1. Is tamper-resistance a business necessity? Ask whether several parties need to verify changes to a record. Tamper resistance does not guarantee correct input. Compare database access controls, audit logs, and signatures as alternatives.
- 2. Does data need to be shared across multiple organizations? A single organization managing its own data is well served by a centralized system. Distributed-ledger value emerges when several independent organizations need to reference and update the same data, and no single party can be designated as the administrator.
- 3. Is proof of ownership or transfer of a digital asset required? Where you need an on-chain way to prove "who owns what" and transfer it without a third-party intermediary, blockchain is an appropriate choice. If certificates, tickets, or points can be managed adequately on your own servers, Web3 isn't needed.
- 4. Do you need to design incentives for participants? Some cases call for a token-economy mechanism that motivates participant behavior without depending on a specific organization. That said, point programs and reward design are achievable with existing services too, so weigh carefully whether a token is actually necessary.
- 5. Can existing technology (an RDB, the cloud) not substitute? This is the most important criterion. If a relational database such as PostgreSQL or MySQL, or a cloud service, can meet the requirements, there is no reason to adopt Web3. Web3 is a powerful technology, but it is at a disadvantage compared with existing technology on complexity, cost, and development speed in many cases.
When we take on a Web3 adoption enquiry, we first examine whether existing technology could substitute. Where Web3 isn't the right fit, we say so clearly and explain why. Staying neutral on technology choice is what determines whether a project succeeds.
Use cases and practical checks
An example is not an adoption justification
Separate the use, the observable fact, and the conditions to check in your project. These examples come from providers. They do not establish Netsujo customer outcomes or general cost savings.
| Use | What the public source establishes | What to check |
|---|---|---|
| Food and supply chains | In 2018, Walmart asked leafy-greens suppliers to introduce farm-level traceability. | Who checks shared inputs and fills gaps? Do not treat a 2018 announcement as proof of current company-wide coverage. |
| Energy | Powerledger describes P2P energy-trading research and development with Elia. | Distinguish an experiment from commercial operation. Check metering data, participants, and existing market arrangements. |
| Enterprise payments | J.P. Morgan describes Kinexys Digital Payments as a permissioned payment and account ledger. | Check eligibility, where funds are held, supported scope, and failure responsibilities. This differs from unrestricted cryptocurrency transfers. |
| Startups and internal services | Tickets, credentials, game items, and points are examples for defining rights and transfer requirements. | Is internal administration sufficient, or must rights move across organizations? NFTs alone establish neither interoperability nor demand. |
Smart contracts and user operations
Automatic execution covers the encoded conditions and available inputs. Code alone does not guarantee physical delivery or business correctness. Define external-data responsibility, error handling, update and stop permissions, and explanations for users. Test whether representative users can manage signatures, fees, lost keys, and recovery in the PoC.
A token is not a required ledger component
Hyperledger Fabric documents consensus that does not need a native cryptocurrency. Deciding that a shared ledger is useful is separate from deciding that a token is necessary. Compare transfer scope, costs, and the source of rewards; do not add a volatile asset where points suffice or assume that more users guarantee a higher price.
DID/VC does not complete identity or privacy design
W3C DID registries are not limited to blockchains. Verifying a credential does not guarantee that its claims are true. Define trusted issuers, status and updates, required disclosures, key recovery, and wallet interoperability. Do not assume that personal information belongs on a public ledger.
What to record in a comparative PoC
Compare the same task under the existing and proposed approaches. Set acceptance criteria for reconciliation time, recovery, approvers, input correction, user completion, and operating costs. Reserve conclusions about speed and savings until you have measurements.
Practical questions before adoption
- Is an ordinary database unsuitable?
- It remains a strong candidate when the parties agree on administration and auditing and it meets requirements. A distributed ledger does not decide input truth or inter-organization agreement for you.
- Should we choose a public or permissioned chain?
- Compare participants, disclosable data, approval rules, and operating responsibility. Do not begin with a chain name or a trend.
- Do we need our own token?
- Not necessarily. Separate the ledger, asset transfers, and rewards; check whether existing payments or points suffice.
- Does DID/VC replace existing identity systems?
- Check the claims to prove, issuers, verifiers, recovery, and interoperability. Adopting a standard does not automatically remove existing identity checks or account operations.
- Should we wait for wider adoption?
- Do not use a universal date. Choose a small use with the necessary participants and operating conditions where you can compare alternatives. Keep untestable conditions explicitly unresolved.
Sources and verification date
Checked September 8, 2026. Provider descriptions, historical announcements, and research plans are treated separately.
Hyperledger Fabric: Introduction
W3C Verifiable Credentials Data Model v2.0
Walmart: 2018 traceability announcement
Powerledger: Elia research project
J.P. Morgan: Kinexys Digital Payments
A decision flowchart
First select the requirements and compare a shared database or existing payment and credential services. Do not exclude a shared ledger simply because asset transfers or a token are unnecessary.
- Q1. Do several parties need to verify and share records? Yes → compare shared ledgers and a shared database. No → use an internal database as the baseline.
- Q2. Can the parties agree on an administrator and change rules? Yes → keep a shared database in the comparison. No → first define agreement and responsibility.
- Q3. Are cross-organization asset transfers required? Yes → verify rights and transfer rules. No → omit asset functionality.
- Q4. Is an independent token indispensable for incentives? Yes → separately verify cost and sustainability. No → compare a token-free design.
- Q5. Can you explain the difference from alternatives and the operational responsibilities? Yes → set acceptance criteria and run a comparative PoC. No → return to requirements.
A difficult gray area: if you need to share data across multiple organizations but can appoint a trusted central administrator, blockchain isn't necessarily required. Compare the cost, performance, and governance of a permissioned or private chain against a centralized system before deciding.
Next steps if you're considering Web3
After narrowing the candidates, we recommend validating technical feasibility and cost-effectiveness through a PoC first, rather than jumping straight into full-scale development.
- Step 1 — Clarify the problem and requirements: document the problem you're solving and why existing technology falls short. Getting stakeholder agreement at this stage speeds up every decision that follows.
- Step 2 — Validate feasibility with a PoC: before full-scale development, confirm technical feasibility, cost, and performance with a small-scale PoC. Estimate the duration from integrations, stakeholder agreement, and verification scope.
- Step 3 — Decide based on the PoC result: use the PoC outcome to decide go, no-go, or pivot. A no-go at the PoC stage is itself a valuable outcome — deciding to stop early minimizes risk.
PoC design in the Web3/blockchain space calls for specialist knowledge — smart-contract specification, testnet usage, and checking regulatory alignment. Getting a rough sense of development cost ahead of time also speeds up budgeting and decision-making.
Summary
Compare tamper resistance, cross-organization sharing, asset transfer, incentives, and differences from existing technology for each use. Some designs use neither tokens nor asset transfers. Choose a design that explains input responsibility, updates, recovery, and the burden on users. Even then, don't jump into full development — validate technical feasibility and cost-effectiveness with a PoC first. Deciding early minimizes development cost and risk.