
dApp Is Dead? The Dilemma Between Decentralization and User Experience in Web3 Applications
TechFlow Selected TechFlow Selected

dApp Is Dead? The Dilemma Between Decentralization and User Experience in Web3 Applications
If we can shift the complexity to the infrastructure layer, building dApps should become much simpler.
Author: w1nt3r.eth
Translation: TechFlow

Maybe blockchains will last forever, but decentralized applications (dApps) have short lifespans.
This Halloween in 2024, I tried opening dApps I used back in 2021—and the results were horrifying: expired domains, paused deployments, page not found errors, services unavailable.
Wait—weren’t these apps supposed to be decentralized? They were meant to be applications independent of centralized entities—free as beer, free as speech, censorship-resistant. The very apps that would make Web3 the new internet.
Yet nearly all of them are gone. Most of the ones I used just two years ago no longer exist. Their "ghosts" might still linger somewhere on-chain—if you can find the right contract address and guess the correct call data.
Why is this happening? Where did things go wrong? And what can we do to change it?
So, what exactly is a “dApp”?
Let’s consult an ancient text from prehistoric times (2016).
"dApp" stands for “decentralized application.” The idea is that you can build a web app using open technologies like HTML/CSS/JS and host it on decentralized, permissionless infrastructure such as IPFS. A dApp interacts with the blockchain through your wallet—fetching live data and sending transactions without relying on centralized companies.
This makes dApps almost unstoppable. Free, permissionless, decentralized. The dream of true digital punk idealism.
Pretty landing pages
But most people don’t care about decentralization or permissionlessness. They care whether an app works—and whether the numbers go up.
Web3 developers quickly realized they’re competing for users’ attention against sleek, fast, engaging Web2 apps—where decentralization offers little competitive edge.
Those deep into tech understand blockchain is a real paradigm shift. But everything on-chain is “open source” and copyable—turning it into a commodity. No moats. Anyone can deploy Uniswap contracts anywhere. In fact, anyone can launch their own L2!
The real differentiators are brand, distribution, network effects, and user experience. Among millions of Uniswap deployments, users pick what they trust (brand), can easily access (distribution), everyone else uses (network effect), and feels intuitive (UX).
I mentioned UX last, but it’s far from least important. Poor UX has real costs. Every e-commerce store owner knows that every extra 100ms of latency can lose 10% of users. You can’t build a premium brand with bad UX. If your app frustrates people, you won’t retain them.

Deploying to Vercel is easier than deploying to IPFS
Doing the right thing is hard
Even though most users aren’t interested in decentralization, real crypto punks still care—not because “everyone should be a decentralization zealot,” but because “it’s the right thing to do.” Decentralization empowers individuals when centralized entities turn hostile or censorious.
Herein lies the problem: building an app that’s both decentralized and delivers great UX is difficult. And the reason it's difficult? Because we (developers) got lazy.
Dissecting BasePaint
Let’s examine a typical modern “dApp” and the tech stack it relies on. I’ll use my own project, BasePaint, as an example. In many ways, it should qualify as a “Web3 dApp”: it uses a blockchain (Base L2) and requires wallet interaction. But that alone doesn’t deliver good UX—so I had to add several non-decentralized components. In fact, quite a few.

Tech stack behind BasePaint
Here are the centralized technologies I had to adopt during development:
-
Domain names. I wanted users to easily find and access our site. Since browsers don’t support ENS natively, I had to buy a domain from a registrar and configure DNS to point to the correct server.
-
Hosting. I needed to host the app (HTML/CSS/JS files) somewhere fast and reliable. While IPFS holds promise, most browsers don’t support it directly, gateways are slow, and URLs are unfriendly.
(Have you ever tried typing
QmRxM6Fz3jYBNLTNn59Whtj8uiFodC53Z5nEep6eSkwf8V on a phone?)
-
Database. Blockchains can work as databases in some cases, but not all. For instance, we store chat messages in a Postgres database—it’s cheaper and faster. We could put it on-chain, but it would never match the speed of a centralized DB.
-
Backend services. BasePaint needs computations unsuitable for Ethereum. Generating videos, syncing cursor positions across users, verifying chat permissions—all require backend logic. We also need to protect sensitive info like DB credentials and private tokens.
-
Ethereum JSON-RPC providers. In theory, we could rely solely on users’ wallets to access the chain. But then users without “Web3-enabled” browsers would see nothing. Worse, different wallet RPC providers behave differently. QuickNode limits log queries to 10,000 blocks, while Alchemy uses its own compute units to rate-limit requests. Relying on wallet RPC means handling all these quirks.
-
Indexer. Storing data on-chain is expensive. BasePaint avoids storing pixels in the contract; instead, it emits all necessary data via Painted events. You *could* reconstruct any canvas by querying smart contract logs. But imagine doing that on the BasePaint gallery page (which displays hundreds of canvases!). To deliver smooth UX, we run an indexer that tracks blockchain events and stores data in a query-efficient format.
-
Other services. We use Reservoir for secondary market data and cross-chain minting, Cloudflare as CDN, R2 for video storage and caching, DataDog for logging, PostHog for analytics, Neynar to resolve Farcaster usernames to wallet addresses. Each service saves us weeks or months of dev time—but makes our app less decentralized. Plus, many lack sustainable business models and could shut down anytime.
-
Credit cards. This one always gets me. Did you know most crypto SaaS tools can’t be paid with crypto? If my credit card balance runs low or expires, my domain, database, servers, RPC endpoints, and other SaaS tools go offline.
How can we decentralize applications?
As a Web3 developer today, here are the options I see:
-
Abandon centralized tech entirely and build a hardcore dApp relying only on decentralized services. This might work for projects like Tornado Cash, but for consumer products, it creates UX barriers that will scare off most users.
-
Keep the centralized app while maintaining a simplified dApp version that uses only decentralized tech. This means maintaining two separate codebases—doubling engineering effort and cost.
-
Adopt a “progressive enhancement” strategy: start with a minimal dApp and enhance functionality if centralized servers are available. This requires careful management and saves little time compared to option two.
-
Open-source the code so others can self-host (our chosen path). But in practice, launching the full system demands high software engineering skill—far more complex than loading a page from IPFS.
All options require significant effort—they’re not default paths. Check any dApp tutorial or template, and these issues are rarely mentioned. Truth is, building dApps shouldn’t be this hard. If we could push complexity down into the infrastructure layer, creating dApps could become much simpler.
Maybe we should tackle the hard problems?
We could try solving this at the infrastructure level. Integrate ENS into getaddrinfo so all browsers natively support it. Make IPFS as fast as top-tier CDNs. Improve Ethereum’s JSON-RPC to better serve dApps. That’s the easy part.
To replace centralized databases and servers, we’d need to invent entirely new technologies that don’t yet exist. Maybe a ZK-based distributed compute system where running code earns rewards—or a super-Ethereum capable of efficiently executing general x86 instructions.
We’d also need decentralized alternatives for every service built around crypto. New incentive models—who pays for compute resources? In truly decentralized systems, current SaaS business models won’t work. (But hopefully, these services could accept crypto payments instead of credit cards.)
Beyond that, the developer experience must be at least as good as today’s centralized platforms. Those platforms have spent billions refining their tools and marketing them across endless tutorials, convincing everyone they’re the best solution.
Does it even matter?
“Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should.” — Jurassic Park
Does the application layer even need to be decentralized?
Nouns shows us that perhaps blockchain-level decentralization is enough. Nouns has a thriving ecosystem of apps—all interacting with the same core contract. You can vote via Camp or Agora, it doesn’t matter—you just pick the interface you prefer.
To attract billions of users, crypto may need to become a seamless component within existing systems. The ideal crypto experience might mean users don’t even realize they’re using crypto—because it’s abstracted away. Like tapping your phone to buy coffee, whether it’s USDC or Visa under the hood doesn’t matter.
The market has converged on a local optimum:
-
The blockchain layer is decentralized, securing trillions in assets and providing strong guarantees for ownership and censorship resistance.
-
The application layer is centralized. Companies build centralized apps to deliver the best UX. Their closed-source systems create competitive moats—but they still all interact with the same blockchain.
The missing tools
I wish this balance leaned further toward decentralization. I want to be able to run my own version of Nouns Camp or Agora locally—just by clicking a link. I want tools that make building such decentralized apps easy, without sacrificing UX.
BasePaint is amazing. It’s a self-sustaining ecosystem: artists create, collectors buy and profit on secondary markets, owners influence operations through voting. It works—we’ve already distributed over $1 million to creators this way.
Yet the weakest link in the entire system is our team. Maintaining the app takes constant effort—fixing bugs, improving UX. At the same time, we’re working to make it more decentralized: making self-hosting easier, relinquishing permissions instead of gating access.
Conclusion
dApps seem lifeless today because the benefits of “decentralization” aren’t yet what users care about—so developers adapt. We’ve stopped building the tools that would make apps truly decentralized.
Luckily, blockchain infrastructure is stronger than ever. Core tech is more robust, roadmaps more promising. We actually have a chance to build a global computing platform.
Unfortunately, discussions around enhancing user interfaces haven’t received enough attention. The concept of dApps has been temporarily shelved…
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News














