What a production Web3 product actually looks like

Most developers think building a Web3 product means writing a smart contract and calling it a backend.

That's not the whole picture.

I have worked on several Web3 products before, and the smart contracts were not the hardest part to build. Most of what we shipped lived off-chain.

On some of those products, the smart contract was maybe 40% of the code. The other 60% was backend infrastructure, which most Web3 tutorials never mention."

The smart contract layer

Yes, there's a contract. It handles what blockchains are actually good at: trustless execution, immutable state transitions, ownership and token logic, and events the rest of the system listens to.

That's it. The contract is a trust anchor for the rules that must be trustless. Everything else lives somewhere cheaper, faster, and easier to change.

What actually runs off-chain

A backend API, REST or GraphQL, that your frontend talks to. Not the chain. An API.

A traditional database like Postgres or MySQL for user profiles, session data, and any application state that doesn't need on-chain guarantees.

An indexer that listens to contract events and writes them to your database. You can't query the chain like a database. No WHERE, no ORDER BY, no joins. RPC calls also have latency and rate limits that hurt UX at scale. So you mirror the chain into a database and query that.

An RPC provider like Alchemy, Infura, or QuickNode, because running your own node is a job nobody wants.

A job queue for async work: notifications, transaction monitoring, ZK proof generation in the background.

A caching layer like Redis, because RPC round trips are too slow for a good UX at scale.

File storage like IPFS, Arweave, or S3, because storing files on most chains is prohibitively expensive.

Authentication is its own piece. Adding a connect wallet button to your Web3 project is cool, but if you want non-Web3-native users to actually use your product, you need to make it more familiar. That means wallet signature verification on the backend, session management, and the same token-based flows any other app has. Your backend still needs to know who the user is.

The misconception that causes the most damage

"Everything is stored on-chain."

Almost nothing is stored on-chain. On-chain storage can be expensive, slow, and unnecessary depending on the kind of data and the blockchain you're building on.

On-chain, you can have ownership records, token balances, critical state transitions, proof verification results.

Off-chain is best for user profiles, metadata, files, and historical data you need to query quickly, as well as anything that changes often.

ZK privacy is a clean example of this split. The proof is verified on-chain, that's the trust guarantee. But the proof generation, the input data, the user session, and the queue managing all of it run in a backend service users never see.

The architecture of a real Web3 product

Frontend
   ↓
Backend API ──→ Smart Contract
   ↓                ↑
Postgres ←── Indexer (chain events → DB)
   ↓
Redis (cache, sessions)
   ↓
Job Queue (proofs, notifications)
   ↓
File Storage (IPFS / S3)

The blockchain sits inside a traditional distributed system, not in place of one.

The exceptions

Some Web3 products genuinely are mostly smart contracts. A pure AMM like Uniswap is mostly contract logic with a thin frontend reading state. Lending protocols like Aave, on-chain perps, prediction markets, vesting and escrow contracts, governance and DAO voting systems, and most pure DeFi primitives lean heavily on the contract because the contract is the product.

You can follow this pattern: if your product is a financial primitive where the rules themselves need to be trustless, and the state is small, you can get away with 80% smart contracts.

If your product has users, content, social features, files, search, notifications, or any kind of UX that doesn't tolerate 12-second confirmation times, you're building a backend.

Most Web3 products fall into the second bucket and don't realize it.

The takeaway

If you're learning Web3 and only focused on Solidity or other smart contract programming languages, you're learning less than half the job.

To build Web3 products that actually scale, you need to understand that the blockchain is one service in a larger system, and the rest of that system has to be built well. Better indexing, better caching, better auth, better UX. The chain alone won't carry the product.