Web3 Explained: What Changes, What Does Not, and When It Is Worth It

Nguyen Manh Thang Chief Executive Officer, AgileTech Vietnam

Published: August 17, 2026
Read time: 16 min

In short

Web3 is a set of technologies for building applications where the user, rather than the operator, holds the credential that controls their assets and identity. That single change is the whole idea, and everything else follows from it: the wallet exists because somebody has to hold the key, the token exists because ownership needs a unit, the public chain exists because a record nobody controls needs somewhere to live, and the fee exists because that record has to be paid for. It is genuinely better than a database for a small number of problems, mainly where assets must outlive the company that issued them or where parties who do not trust each other need one shared record. For everything else it is a slower, more expensive, and less recoverable way to do what a normal database already does well, and the honest answer to most product questions is that you do not need it.

Web3 is unusual among technology topics in that the explanations tend to fail in both directions. The enthusiastic ones describe a new internet without saying what actually changes in a piece of software. The dismissive ones say it is all speculation without engaging with the two or three problems it genuinely solves better than the alternative. Neither helps somebody who has to decide whether to build something.

This article is written for that decision. It explains the vocabulary properly, because most confusion about Web3 is vocabulary confusion rather than concept confusion. It compares Web 2.0 and Web 3.0 on the specific properties that change how a product behaves, rather than on ideology. It works through play to earn economies honestly, since that is where most of the money and most of the failures went. And it ends with a three question test that we use with clients, which usually concludes that a blockchain is not needed, and occasionally concludes that it is.

We write it from the build seat rather than the investment seat. Our teams have shipped chain-backed products and, more often, talked clients out of them, and the failure patterns below come from that work. If you want the commercial view of what we do in this space, that lives on our blockchain development services page. This article deliberately does not sell anything until the end.

Key takeaways

The one real change is who holds the key. In Web 2.0 the operator holds your credential and can reset it, freeze it, or revoke it. In Web 3.0 you hold it, which means nobody can take your assets and nobody can give them back either.
A wallet is not an account. It is a key pair with a balance attached. There is no password reset, no support team who can help, and no way back from a lost recovery phrase, which is the single largest reason mainstream users abandon these products.
A token is a row in a shared ledger with a transfer rule. That is all. Whether it is worth anything depends entirely on whether somebody outside the system wants it for a reason other than reselling it.
Most play to earn economies fail for the same arithmetic reason. If new player deposits are the main source of the reward pool, rewards must shrink as growth slows, and the shrinking is what ends the game.
Almost nothing belongs on chain. In every serious build, ownership and settlement go on chain and the entire rest of the application, profiles, media, search, feeds, analytics, stays on ordinary infrastructure.
Three questions decide it. Must the asset outlive your company? Do untrusting parties need one shared record? Does somebody outside your organization need to verify it independently? If all three are no, a normal database is the correct answer.
The costs are structural, not temporary. Every write costs a fee, every read needs an indexer to be usable, and every mistake is permanent. Those are properties of the design, not problems awaiting a release.

The one thing that actually changes

Strip away the terminology and there is exactly one structural change between the web most people use and the web these technologies describe. In the familiar model, when you own something inside a product, a photo, a balance, a game item, a username, what you actually own is a row in the operator’s database plus their commitment to honor it. Your credential is a password they hold a hash of, and they can reset it for you when you forget, which means they can also reset it without you. That is not a criticism, it is the mechanism that makes password recovery and fraud reversal possible.

In the other model, what you own is a record in a ledger that the operator does not control, and your credential is a private key that only you hold. Nobody can move your assets without that key. The consequence people celebrate is that nobody can take your assets. The consequence people discover later is the same sentence: nobody can take your assets, including you, if you lose the key, and including the support team you are emailing at two in the morning.

Everything else in the Web3 vocabulary is a consequence of that one change. Somebody has to hold the key, so there is a wallet. Ownership needs a countable unit, so there are tokens. A record nobody controls needs to live somewhere that nobody controls, so there is a public chain maintained by many independent parties. Maintaining that shared record costs real resources and cannot be funded by an operator who does not exist, so every change to it carries a fee. Reading a shared ledger efficiently is a different problem from writing to it, so there are indexers. None of this is arbitrary; it is all downstream of moving the key.

It is worth being equally clear about what does not change. The interface is still HTML and CSS in a browser or a native app. The product still needs search, notifications, onboarding, moderation, analytics and customer support, and none of those are improved by a chain. Payments still need a way in from ordinary money. The engineering craft of building a good application is entirely unaffected, which is why a Web3 product with a bad interface is simply a bad product, and quite a lot of them were.

The vocabulary, defined by what it does rather than by what it enables

Private key: A large secret number that proves control of an address. Whoever has it can move everything at that address. It is not a password, because there is nothing to reset it against and nobody who could authorize the reset.
Wallet: Software that stores a private key and signs transactions with it. It is closer to a keyring than an account. The balance it displays is not stored inside it; it is read from the chain.
Recovery phrase: A human-readable encoding of the key, typically twelve or twenty-four words. Whoever reads it owns the assets. This is why writing it in a note-taking app is equivalent to publishing it.
Public chain: A shared, append-only record maintained by many independent operators who agree on its contents by a defined rule. Nobody can edit history, which is the point and also the constraint.
Transaction: A signed instruction to change the shared record. Costs a fee, takes time to be accepted, and cannot be undone once it is. There is no equivalent of a chargeback.
Gas fee: The payment for the computation and storage a transaction consumes. It varies with demand, which means the cost of an action in your product is set partly by unrelated activity elsewhere on the chain.
Smart contract: A program stored on the chain that runs when called, with its own storage and balance. Public, usually immutable once deployed, and therefore the highest-risk code your team will write.
Token: A balance tracked by a contract, transferable under the rules that contract defines. Fungible tokens are interchangeable units. That is the entire technical content of the word.
NFT: A token where each unit is distinguishable, so it can represent one specific thing. What it represents is a matter of the contract and the surrounding legal reality, not of the technology.
On chain and off chain: Whether a piece of data lives in the shared record or in ordinary storage. Almost everything in a working product is off chain, including nearly always the image an NFT points at.
Indexer: A service that reads chain events and stores them in a normal queryable database so your application can answer questions quickly. Every usable product has one, which is worth noticing.
Custody: Who holds the key. Self custody means the user does, and accepts the loss risk. Custodial means a company does, and you have recreated the model you left, with more steps.

The support problem that decides mainstream viability

Every consumer product has a recovery path, because users forget things. The password reset email is not a minor feature, it is the mechanism that lets a product survive contact with ordinary human memory. Self custody removes it entirely and offers nothing in its place.

Teams discover this after launch, in support tickets that cannot be resolved. The workable answers are all compromises: custodial wallets where you hold the key and accept the regulatory weight that comes with it, social recovery where several trusted parties can jointly restore access, or a hybrid where the account is ordinary and only specific assets are self-custodied. Choose deliberately before launch. Discovering it afterward means telling real users their assets are gone, which is the one support conversation from which a consumer brand does not recover.

The weightings are a judgment about where the change lands, offered to make one point: five of these six rows are infrastructure concerns, and the row that decides whether users like the product is the one that barely moves. The row labels are compressed to fit the chart, so in full: ownership moves to a shared ledger instead of a single company database, writes become structurally slower and more expensive and stay that way, and reads still come from an ordinary database that an indexer keeps up to date.

Web 2.0 against Web 3.0, on properties rather than principles

The comparison is usually framed as centralized against decentralized, which is a statement about values and does not help anybody choose. The useful comparison is on properties: what happens in each model when a specific thing goes wrong or a specific thing needs to be true. Framed that way it becomes clear that neither model is better in general and each is decisively better for particular requirements.

Take permanence. If a platform shuts down, everything in its database goes with it, and the history of the consumer web is largely a history of that happening. If a product built on a public chain shuts down, the ownership records survive it, because they were never in the product’s custody. Somebody can build a new interface over the same assets. That is a genuine, hard-to-replicate property, and it is the single best reason to use this technology. It matters when the asset is meant to outlive the issuer, and it is worth nothing at all when the asset is meaningless without the product, which describes most products.

Take reversibility, and the sign flips. In an ordinary system a mistaken transfer, a compromised account or a fraudulent charge can be reversed by an operator applying a policy. On a public chain a completed transaction is final. For a settlement system between institutions that is a feature, because finality is what settlement means. For a consumer application it is a defect, because consumers make mistakes constantly and expect help.

Take cost and speed. A write to a database you run is effectively free and completes in milliseconds. A write to a public chain costs a fee that varies with demand you do not control, and completes in seconds to minutes. No release will change this, because the cost is what pays the independent operators to maintain a record nobody owns. Any design that puts a high-frequency action on chain, every message, every move in a game, every profile edit, is fighting the mechanism rather than using it.

And take trust. This is the property the technology is genuinely built around. If two parties who do not trust each other need to agree on one record, and there is no operator both will accept as the keeper of it, a shared ledger solves a problem that is otherwise solved by lawyers and reconciliation. If a trusted operator does exist, and in most products the company building it is that operator, then a database run by them is not a compromise, it is the correct architecture.

Which model is better, by requirement

Requirement	Better model	Why
Assets must outlive the issuing company	Web 3.0	Ownership records are not in the company’s custody, so a shutdown does not erase them.
Untrusting parties need one shared record	Web 3.0	Removes the need to agree on whose database is authoritative, which is often the harder negotiation.
Anyone must be able to verify independently	Web 3.0	The record is public and the rules are inspectable, so verification needs no cooperation from you.
A mistake must be fixable	Web 2.0	Reversal requires an operator with authority. Finality and fixability are opposites.
Actions are frequent and low value	Web 2.0	A per-write fee and multi-second confirmation make high-frequency interaction unusable.
Personal data is involved	Web 2.0	An immutable public record and a legal right to erasure cannot both be satisfied.
Users will forget their credentials	Web 2.0	Recovery needs an authority. Self custody has none, by design.
Reads must be fast, filtered and searchable	Web 2.0	This is what an indexer restores, which means a normal database was doing the work anyway.

Read this by requirement rather than by column. Any real product has requirements in both columns, which is exactly why the serious builds are hybrids rather than one or the other.

How the comparison gets used well and badly

Do this

Pick the property, then the modelWrite down the requirement that makes a chain necessary in one sentence. If you cannot, that is the finding, and it saved you a year.
Assume a hybridOwnership and settlement on chain, everything else off it. This is what every product that works actually does, whatever its marketing says.
Decide custody before designSelf custody, custodial or social recovery changes the onboarding, the support model and the regulatory position. It is an architecture decision, not a settings screen.
Budget for the auditContract code is public, immutable and holds value. An independent security review is not optional and is not cheap, and it belongs in the plan from the start.

Not this

Putting the application on chainProfiles, messages, media and analytics on a public ledger is slow, expensive, permanently public, and gains nothing. Only ownership needs to be there.
Adding a token to fix retentionA token is a unit of ownership, not a growth mechanism. If the product is not compelling without one, the token buys attention that leaves when the reward does.
Treating immutability as a feature everywhereIt is a feature for a settlement record and a liability for anything containing user data, since it forecloses correction and erasure.
Calling a private chain decentralizedA ledger where one organization controls every node is a database with worse tooling. If that is the right answer, use the database and keep the tooling.

Three of these six rows are worse in the right-hand column and are shown that way deliberately. They are not defects awaiting a fix; they are the price of the two rows above them, and a decision to build this way is a decision to pay it.

Play to earn, and the arithmetic that ended most of it

Play to earn deserves its own section because it is where the largest number of these products were built, where the largest number of ordinary people encountered the technology, and where the failures were most severe. The idea is straightforward and not inherently unreasonable: players earn transferable assets through play, those assets have value outside the game, and so time spent playing produces something real. The problems are not with the idea. They are with where the value comes from.

Any reward pool has to be funded by something. There are only a few candidates: money brought in by new players, money paid by existing players for something they actually want, sales from a studio-held reserve, or outside money such as sponsorship. Only the second and fourth are sustainable at scale, because the first depends on continuous growth and the third depends on a finite reserve. This is not a claim about any particular game; it is an accounting identity. Value paid out has to come from somewhere, and there are not many somewheres.

When new player deposits dominate, the outcome is determined in advance. Rewards are attractive while player growth is fast, because inflows exceed outflows. As growth slows, and growth always slows, the same reward schedule becomes unaffordable and has to be cut. Cutting it reduces the reason players joined, which slows growth further. The mechanism is self-reinforcing in both directions, which is why these economies look extraordinary and then look terrible with very little time in between.

The second failure is subtler and affects games whose funding is sound. If earning is the point, players optimize for earning, and optimizing for earning is usually not fun. The most efficient way to accumulate a reward is normally the most repetitive one, so the population drifts toward players who tolerate repetition for income, and away from players who wanted a game. Studios then face a choice between a fun game with weak earning and an efficient earning machine with weak play, and the assets are worth something only while the second group keeps arriving.

None of this means transferable game assets are a bad idea. It means the value has to come from players wanting the asset for its use inside a game they would play anyway. Sell items people want, let them be resold, take a fee on the resale. That model is old, it works, and it does not require anyone’s deposit to fund anyone else’s reward. What it does require is a good game, which is the expensive part that a token cannot substitute for.

How the collapse runs, in order

Launch with generous rewardsMonths 0 to 3

Inflows from new players far exceed payouts, so the reward schedule looks affordable. Early participants earn well and say so publicly, which accelerates arrivals.
Growth becomes the funding modelMonths 3 to 8

Deposits are now the main source of the pool. Nobody planned this; it is simply where the money is coming from, and it is invisible unless somebody measures the split.
Arrivals slow for ordinary reasonsMonths 8 to 12

Market attention moves, acquisition costs rise, the novelty fades. Outflows now exceed inflows and the asset price begins to drift down.
Rewards are cut to protect the economyThe decision point

Correct in isolation and fatal in context. The reason for playing was the reward, so the cut removes the reason, and the players who arrived for income leave for the next thing.
The remaining players are the ones who liked the gameThe steady state

This population is much smaller than the peak and, importantly, is the population the studio should have built for from the beginning.

What has to be true for a transferable asset economy to survive

The game is worth playing with rewards switched offThis is the test. If nobody would play for free, the token is the product and the product is a queue of people waiting for someone behind them.
Rewards are funded by spending, not depositsMeasure the split explicitly and report it monthly. An economy funded by arrivals is on a schedule whether or not anybody has noticed.
Assets have use before they have priceAn item that makes play better has a floor set by that usefulness. An item whose only property is scarcity has a floor of zero.
Sinks remove as much as sources addCrafting, repair, entry fees, consumption. Without a sink, supply only rises, and rising supply against flat demand has one outcome.
The studio does not need to sell reserve to operateIf operating costs are covered by treasury sales, the studio is a seller into its own market, and its interests and its players’ interests are opposed.
Rules changes are announced before they happenSilent parameter changes to an economy people hold assets in destroy trust faster than the change itself does, and trust is the only thing holding the price up.

These are preconditions rather than improvements. An economy missing any of them can still grow, and the growth is what makes the eventual correction severe.

An illustrative decomposition to make one structural point, not a measurement of any real game. The two durable sources, utility and sponsorship, total under a fifth. An economy in this shape does not need bad luck to correct; it corrects when growth slows, which growth always does.

What goes on chain, which is much less than people expect

The most common architectural error in this space is putting the application on the chain. It comes from taking the language literally: if this is a decentralized application, surely it runs on the decentralized thing. In practice a working product uses the chain for a narrow and specific purpose and does everything else on ordinary infrastructure, and the products that tried otherwise are slow, expensive and mostly gone.

The chain is good at exactly one job: holding a record of who owns what, in a way that nobody including you can quietly change. Give it that job and nothing else. Ownership, transfer, and the settlement of value belong there. Profiles, media, search indexes, feeds, notifications, moderation state, analytics, session data and anything containing personal information belong in normal storage, for reasons ranging from cost to latency to the legal impossibility of deleting from an immutable public record.

Reads deserve particular attention, because this is where the architecture surprises teams. A chain is a poor query engine. It can tell you the state of a specific record cheaply, and it cannot answer "show me the twenty most recently traded items in this category, sorted by price" in any reasonable time. So every usable product runs an indexer: a service that listens to chain events, writes them into a conventional database, and serves the application from there. Once you see that, you see that a normal database is doing the read work in every one of these products, and the chain is doing something much more specific than the marketing suggests.

Two further pieces are needed by any product with mainstream users, and both are ordinary software. An on-ramp converts real money into whatever the chain uses, which brings identity verification and regulatory obligations with it. And a signing strategy decides how often the user has to approve something with their key, because a design that prompts for a signature on every interaction will be abandoned, and one that never prompts has quietly taken custody. Session keys with narrow scopes and short lifetimes are the usual compromise, and getting that scope wrong is a security defect rather than a convenience one.

The division of labor in a product that works

On chain, and nothing more

Ownership records: Who holds which asset. The one thing that genuinely needs to be outside your custody, and the reason the whole architecture exists.
Transfer rules: The contract logic governing how ownership moves, including royalties and restrictions. Public and inspectable, which is the point.
Settlement of value: The final movement of funds, where irreversibility is the desired property rather than an accepted cost.

Off chain, on ordinary infrastructure

Media and content: Images, video, documents. Too large and too expensive to store on chain, so a reference is stored instead and the file lives elsewhere.
Profiles and social data: Names, avatars, follows, messages. Mutable by nature and frequently personal, which rules out an immutable public record.
Search and feeds: Anything requiring filtering, ranking or aggregation. This is an indexer plus a normal database, always.
Analytics and moderation: Product measurement and abuse handling. Both need to be revisable and neither benefits from being public.

The connective pieces people forget to budget

Indexer: Turns chain events into queryable rows. Needs monitoring, reorg handling and backfill, and is a real service with real operational cost.
Fiat on-ramp: Converts ordinary money in. Brings identity verification, regional restrictions and a partner dependency into your product.
Signing strategy: How often and for what the user signs. Scoped session keys with short lifetimes, because prompting for everything loses users and prompting for nothing takes custody.
Contract audit and upgrade path: Independent review before deployment, and a decided answer on whether contracts can be upgraded. Both are expensive and neither is optional.

The test for any piece of data: does somebody outside your organization need to verify it without your cooperation? If not, it does not belong on chain, whatever the diagram in the pitch deck said.

The clearest sign a chain-backed product was designed rather than declared is that you can describe, in one sentence, the single thing on the chain. If the answer takes a paragraph, the chain is being used as a database, and it is a bad one.

A principle we apply in architecture reviewAgileTech engineering practice

The tier notes are compressed to fit the diagram, so in full: the client tier is ordinary application code, the read path is a conventional database in every case without exception, the on chain tier carries ownership and settlement and nothing else, and the supporting services are ordinary software carrying ordinary regulatory and operational obligations. Count the boxes: twelve, of which two are on chain. That ratio is not a compromise made under time pressure, it is what a correct design looks like, and a diagram with more than two boxes in the highlighted tier is usually describing a product that will be slow and expensive.

The three question test, and what to do with a no

When a client asks us to build something on a chain, we ask three questions before discussing anything technical. They are deliberately narrow, and in our experience a product that answers no to all three is better built on ordinary infrastructure, without exception so far.

First: must the asset outlive your company? Not should it ideally, but must it, such that a shutdown erasing it would be a genuine failure to the holder. A land title, a professional credential, a transferable license, a durable collectible: yes. A loyalty point, a subscription entitlement, an in-app currency: no, because those are worthless the moment the product stops existing anyway.

Second: do parties who do not trust each other need one shared record, with no operator all of them will accept? This is the strongest case the technology has. Multi-party supply chain provenance, cross-institution settlement, consortium arrangements where each member currently keeps their own version and reconciles by email. If your organization is a party everyone already trusts, and it usually is, then your database is the shared record and the problem does not exist.

Third: does somebody outside your organization need to verify a fact independently, without your cooperation, and would your assurance not be sufficient? Public issuance records and auditable reserves qualify. Internal reporting does not, because the auditor asks you and you answer.

If all three are no, the recommendation is a normal database, and the saved budget is better spent on the product itself. That is not a dismissal of the technology; it is what the test is for. If one is a firm yes, the design is a hybrid: that specific record goes on chain and everything else stays where it belongs, which is the architecture in the previous section. And if you are unsure, build the product on ordinary infrastructure first, with ownership modeled cleanly enough that it could be moved later. Nearly every product that added a chain successfully did it that way round, and nearly every one that started with the chain spent its first year on infrastructure instead of on whether anyone wanted the thing.

The four cases, and what each one should actually build

We are being asked to build something on a blockchain. How do we decide?

The asset must survive our company shutting down

Ownership records on chain, everything else off it

This is the property a database genuinely cannot provide, because your database is in your custody by definition. Keep the on-chain surface to ownership and transfer alone.
Untrusting parties need one shared record and no operator is acceptable to all

A shared ledger for the record they dispute, and nothing else

The chain replaces the negotiation about whose system is authoritative, which is usually harder than the engineering. Put only the disputed facts on it.
An outside party must verify independently, without our cooperation

Publish the specific verifiable facts on chain, keep the system off it

Verifiability is a property of the published record, not of the application. A small public record over an ordinary system is enough.
None of the above, but a token is wanted for growth or fundraising

Build on a normal database and revisit in a year

A token does not fix a product nobody wants, and it adds regulatory exposure, permanent public state and an audit bill. Spend the money on the product and keep the option open.

What the test tends to conclude, in our experience

3 questions Asked before any technical discussion The answers change the whole architecture rather than one component, which is why they come first.

2 of 12 Boxes actually on chain in a working design A judgment from the architecture in this article, not a survey. The other ten are ordinary software with ordinary costs.

1 sentence A good answer to what is on the chain If the answer runs longer than that, the chain is being used as a database.

Three branches rather than four, because a fourth reduces each outcome box to a slogan. The fourth case worth naming is the one where a token is wanted for growth or fundraising rather than for ownership: that is the same answer as the third branch, build on a normal database, plus the observation that a token adds regulatory exposure and permanent public state to a product that has not yet proved anybody wants it.

If the answer is yes: what building it actually involves

Suppose one of the three questions was a firm yes. The build is then a fairly ordinary software project with three unusual properties, and being explicit about them at the start is most of what separates a smooth delivery from a difficult one.

The first is that some of your code is public, immutable and holds value. A smart contract cannot be quietly patched on a Friday, its source is readable by anyone including people looking for a mistake, and a defect in it can be exploited for the full value it controls. That changes the engineering discipline required: a specification written before the code, an independent audit before deployment, a decided and documented upgrade strategy, and a deployment process treated with the seriousness of a database migration that cannot be rolled back. None of this is exotic, but all of it is more rigor than most application code receives.

The second is that your product now depends on infrastructure you do not operate and cannot escalate to. Fees rise when unrelated activity spikes. Confirmation times vary. Chains have outages and forks. A node provider can rate-limit you. Your design has to degrade gracefully through all of that, which in practice means the read path keeps serving from your own database while writes queue and retry, and the interface tells the user honestly what is pending rather than pretending an action completed.

The third is that the user experience problems are genuinely hard rather than merely unpolished. Wallet installation loses a large share of first-time users. Signature prompts frighten people and rightly so, since a signature can authorize more than it appears to. Recovery phrases get lost. Fees confuse. Every one of these has a mitigation, and they are all compromises: custodial or social-recovery wallets, sponsored transactions so the user does not hold the chain’s currency, session keys so signing is occasional, batched writes so the fee is amortized. Choose them deliberately, because each trades a little of the decentralization you came for in exchange for a product ordinary people can use.

The delivery shape we recommend follows from all three. Model ownership cleanly in an ordinary system first and get the product working. Add the chain for the narrow record that needs it, behind an interface your application talks to, so the chain is a dependency rather than a foundation. Audit before value is at stake, not before launch, since those are different dates. And instrument the on-ramp and the wallet steps from day one, because that is where your users will actually be lost, and it will not be where anyone expected.

A delivery shape that survives contact with real users

ModelWeeks 1 to 3

Write the one sentence describing what goes on chain. Model ownership and transfer in an ordinary system. Decide custody: self, custodial, or social recovery.

Done when A written specification of the on-chain surface, and a custody decision with its support and regulatory consequences named.
Build off chainWeeks 3 to 10

The whole product on ordinary infrastructure, with ownership behind an interface. Real users, real feedback, no chain dependency yet.

Done when A product people use, where the ownership interface has exactly one implementation and could accept a second.
Contract and auditWeeks 8 to 14

Specification, implementation, tests including adversarial ones, then independent audit. Upgrade path decided and documented before deployment.

Done when An audited contract on a test network, with findings resolved and the upgrade decision written down rather than assumed.
Integrate and instrumentWeeks 12 to 18

Indexer, on-ramp, signing strategy, retry and degradation behavior. Instrument every step of wallet setup and first purchase.

Done when Chain writes working under simulated congestion, reads served entirely from your own database, funnel measured step by step.
Launch narrow, then widenWeek 18 onward

A limited cohort with real value at stake. Watch the funnel and the support queue, which is where the honest verdict lives.

Done when Drop-off understood and reduced at the wallet and on-ramp steps, and a support model that can answer the question about a lost phrase.

Questions worth asking a team that proposes this

Whether you are evaluating an internal proposal or an external partner, the useful questions are not about which chain or which framework. They are about whether the person answering has thought about the parts that are unglamorous and expensive. A team that answers these crisply has built one of these before. A team that treats them as details has not.

Ask what exactly is on the chain, and expect one sentence. Ask what happens when a user loses their recovery phrase, and expect a policy rather than sympathy. Ask how a filtered, sorted list is served, and expect the word indexer without prompting. Ask who audits the contract and when, and expect a name and a date rather than an intention. Ask what happens when fees spike tenfold during a launch, and expect a described behavior rather than an assurance that it is unlikely.

Then ask the uncomfortable one: what would make you recommend against using a chain here? A team that cannot answer that has one tool, and you are about to become the thing it is used on. Our own answer is the three question test in the previous section, and we apply it before quoting, which occasionally costs us the work and has never once cost a client a working product.

If you are weighing a partner for this or any other build, the general criteria are in our guide to evaluating a software development partner, and the questions there apply with more force here, because the code is public and the mistakes are permanent. If you would rather start from the delivery side, we are a software development partner in Vietnam with teams who have shipped chain-backed products and, more often, talked clients out of them.

What a good answer sounds like, and what a worrying one sounds like

Question	A good answer	A worrying answer
What exactly is on the chain?	One sentence naming ownership and transfer, and nothing else.	A list of everything the product does, or a diagram instead of a sentence.
A user lost their recovery phrase. What now?	A named policy: custodial, social recovery, or an explicit and disclosed loss.	"We educate users about key management."
How is a sorted, filtered list served?	"An indexer writes chain events into a normal database and we read from there."	"We query the chain." This product will be slow and they have not built one.
Who audits the contract, and when?	A firm and a date before any value is at stake.	"We will get it audited before launch." Launch and value at stake are different dates.
Fees spike tenfold during our launch week. What happens?	Writes queue and retry, reads unaffected, the interface tells the user honestly.	"That is unlikely." It is not, and unlikely is not a behavior.
Can the contract be upgraded?	A decision either way, with the trust and risk consequences stated.	An assumption that it can, which usually means an admin key nobody has discussed.
What would make you advise against a chain?	A specific test, applied before quoting.	Nothing, or a reframing of the question. This is the answer that should worry you most.

The pattern in the right-hand column is confidence without specifics. It is not dishonesty, usually. It is a team that has read about this rather than operated it, which you will find out later and more expensively.

Frequently asked questions

What is Web3, in one paragraph?

Web3 is a way of building applications where the user holds the credential that controls their assets, instead of the operator holding it on their behalf. That single change produces everything else: a wallet to hold the key, tokens as units of ownership, a public chain to hold a record nobody controls, and a fee on every change to that record because maintaining it costs real resources. It is a better answer than a database when an asset must outlive the company that issued it, or when parties who do not trust each other need one shared record. For most products neither is true, and a database is the correct choice.

What is the difference between Web 2.0 and Web 3.0?

The difference that matters is custody of the credential. In Web 2.0 the platform holds your credential, which is why it can reset your password, reverse a fraudulent charge and delete your data on request, and also why your assets disappear if the platform does. In Web 3.0 you hold the key, so nobody can take your assets and nobody can recover them either. Everything else follows from that: writes cost a fee and take seconds instead of milliseconds, mistakes are final, and the ownership record survives the application. Neither model is better in general. Each is decisively better for particular requirements, which is why serious products use both.

Do we need a blockchain for our product?

Probably not, and there is a three question test that settles it quickly. Must the asset survive your company shutting down, such that its loss would genuinely harm the holder? Do parties who do not trust each other need one shared record with no operator all of them accept? Does somebody outside your organization need to verify a fact without your cooperation? If all three are no, a normal database is the right answer and the saved budget belongs in the product. If one is a firm yes, the design is a hybrid: that record goes on chain and everything else does not.

What is a wallet, and why do users struggle with it?

A wallet is software that holds a private key and signs transactions with it. It is not an account, because there is no server storing your credentials and therefore nothing to reset. Users struggle for three reasons that are all structural rather than cosmetic. Installation is an extra step before any value is delivered, and a large share of first-time users stop there. Signature prompts ask people to authorize something they cannot fully read, which is a reasonable thing to be nervous about. And a lost recovery phrase is unrecoverable, with no support path, which is unlike every other product they use. Custodial wallets, social recovery and scoped session keys each mitigate some of this by trading away some of the independence that motivated the design.

What is an NFT, really?

Technically it is a token where each unit is distinguishable, so one unit can refer to one specific thing. That is the whole technical content. What it actually represents depends on the contract and on the legal arrangement around it, not on the technology, and in most cases the file itself is not on the chain at all: the token holds a reference and the image lives in ordinary storage. This matters because two NFTs with identical technical properties can carry completely different rights, and the difference is written in the terms, not in the code. Ask what the holder is entitled to and who guarantees it. If the answer is unclear, the answer is that they are entitled to the token.

Why did so many play to earn games fail?

Because of an accounting identity rather than bad luck. Rewards paid to players have to be funded, and the candidates are new player deposits, spending by players who want something, sales from a studio reserve, or outside money. When deposits are the main source, the reward schedule is only affordable while arrivals keep accelerating. Arrivals always slow eventually, at which point rewards must be cut, and cutting them removes the reason people joined, which slows arrivals further. A second problem compounds it: if earning is the point, players optimize for earning, and the most efficient way to earn is usually the most repetitive, so the population drifts away from people who wanted a game. Transferable game assets can work, but the value has to come from players wanting the item inside a game they would play anyway.

How much of an application actually runs on the chain?

Very little, in every product that works. Ownership, transfer rules and the settlement of value go on chain. Profiles, media, search, feeds, notifications, moderation, analytics and anything personal stay on ordinary infrastructure, partly for cost and speed and partly because an immutable public record and a legal right to erasure cannot coexist. Reads are the detail that surprises teams: a chain is a poor query engine, so every usable product runs an indexer that copies chain events into a conventional database and serves the application from there. In a typical architecture diagram of a dozen components, two are on the chain.

Is a private or permissioned blockchain a good middle ground?

Rarely, and it is worth being blunt about why. The properties that make a public chain valuable, that nobody controls the record and anybody can verify it, come precisely from the fact that many independent parties maintain it. A ledger where one organization runs every node has none of those properties and keeps all of the costs: slower writes, harder queries, immutability where you may want correction, and a much smaller pool of engineers who can work on it. It is a database with worse tooling. The one case with genuine merit is a consortium where several organizations that do not trust each other each run nodes, because then the independence is real, and at that point the hard part is the governance agreement rather than the software.

If someone has proposed a chain for your product and you want the three questions in this article answered against your actual requirement rather than against a pitch deck, a software development partner in Vietnam with engineers who have shipped chain-backed products, and talked more clients out of them than into them, will tell you which answer your case gives before you commit a budget to it.

Web3 explained: what changes, what does not, and when it is worth it