“If we can already track digital assets and their ownership in our Web2 system, what additional value would Web3 create?”
This is the question that the CPO of a US-based sports technology company asked the ND Labs team during a product discussion. The company is developing a platform that enables sports fans to interact with teams and athletes through digital collectibles, rewards, auctions, and other digital assets.
The company already plans to track ownership of these assets within its own system. Its reservations about adding blockchain are therefore entirely reasonable.
This conversation prompted the ND Labs team to examine a broader product question: when does blockchain create meaningful value, and when is a conventional database the better choice?
A conventional database is perfectly capable of keeping track of digital items, because it can store information about:
If the asset is never supposed to leave the platform and users fully trust its operator, blockchain may not provide the product with any noticeable advantage.
In other words, merely turning a database record into a token does not create value.
Web3 becomes useful when a product requires not only internal record-keeping but also independently verifiable digital ownership.
In Web2, the user does not actually own the asset. They own an account that the platform permits to use a particular digital object. At the same time, the platform retains full control and if the platform changes the rules, they can block the account, restrict the transfer of the asset, or shut down the service.
In Web3, an asset can be linked to the user’s wallet and exist independently of the application’s internal database. This creates several additional possibilities:
It is possible to confirm who issued the asset, when it was created, and which wallets it passed through. For rare sports collectibles, such a history of provenance may be part of their value.
The asset can potentially be used across other applications, marketplaces, games, or fan communities, provided that these products support the relevant standards and integrations.
Portability does not necessarily have to be available from day one. The platform can keep all operations within the application while preserving the ability to expand the ecosystem later.
A token can provide access to gated content, events, discounts, voting, or special offers. For example, a digital athlete card can simultaneously be:
If a user sells an asset, a smart contract can automatically distribute a fee among the platform, club, athlete, or another rights holder.
This can also be implemented in a centralized system. The difference is that the rules of a blockchain asset can be verifiable and can apply beyond a single marketplace.
The CPO then raised another important product consideration:
We want everything to remain inside the application. Why do we need blockchain, then?
Using blockchain does not mean that the product must send users to external exchanges or force them to understand cryptocurrencies.
The interface can remain completely familiar:
Seed phrases, network fees, and technical details can be hidden beneath the product interface.
Thus, Web3 can operate as an infrastructure layer without turning the application into a traditional crypto product.
However, there is an important caveat: if the asset remains inside a closed system forever and the user receives no additional rights, blockchain risks becoming an expensive replacement for a conventional database.
The discussion also highlighted an important architectural distinction between payment processing and digital asset management.
Stripe is a payment processing platform that allows businesses to accept card and other fiat payments. It does not store or manage the digital assets themselves.
In this architecture, Stripe processes the payment, while the application’s Web3 infrastructure issues the digital asset and assigns it to the user’s embedded wallet.
A typical scenario works as follows:
The user does not need to purchase an internal token or cryptocurrency first. They can pay using a familiar method, while the blockchain operations take place automatically in the background.
This separates the two functions clearly:
As a result, the product can provide blockchain-based ownership without introducing unnecessary friction into the payment experience.
The company is currently rebuilding its core product. At this stage, the CPO’s primary concern was prioritization: while tokenization and a marketplace might become useful later, the team first needs to launch the product’s core functionality.
This is a sound product approach.
Web3 does not necessarily have to be implemented to its fullest extent immediately. A phased strategy is possible:
This approach reduces technical and market risk. The goal is not to test users’ interest in the term “Web3,” but to validate whether the feature creates real product value.
A product should not move to Web3 simply because tokenization is being discussed by the market again. Blockchain makes sense if it creates at least one significant advantage:
If there are no such requirements, a Web2 architecture will probably be simpler, cheaper, and more convenient.
“What will the user be able to do after Web3 is implemented that they cannot reliably and conveniently do today?”
If the team has a clear answer, it can discuss blockchain, wallets, and tokenization. If there is no answer yet, it should begin not with the technology, but with the product value.
