2025-12-14

Web3 Product Readiness Checklist

Before you ask someone to connect a wallet, a few things should already be true: contracts reviewed, gas explained in the UI, and failed transactions handled with a message a human wrote. A checklist we use before launch.

7 min read

Web3 Product Readiness Checklist

Shipping a dApp is easy; shipping one that people trust with real money is not. This checklist is what we walk through with teams before mainnet, not because every box needs a green check for a slide deck, but because skipping one of these usually shows up as support tickets, bad press, or worse.

Who this is for

Product and engineering teams building anything that touches a public chain: wallets, NFT mints, governance, payments. If your users see “connect wallet,” this list is for you.

Before mainnet

  • [ ] Smart contracts audited by someone who does this for a living, with issues fixed or explicitly accepted. Toy contracts on testnet are fine; anything holding value or permissions is not.
  • [ ] Gas and fees explained somewhere a non-crypto person can read. Ballpark costs under normal load and under congestion, even if it is a range.
  • [ ] Wallet and chain flows tested on the browsers and wallets you claim to support. Wrong network errors should say what to do next, not “execution reverted.”
  • [ ] Failed transactions handled with clear copy for timeouts, reverts, and out-of-gas. Silence is worse than an error message.
  • [ ] Indexer or subgraph matches reality if the UI depends on it. Have a plan for reorgs and delayed blocks so the dashboard does not lie for ten minutes after a trade.

Security basics

  • Roles and admin actions live behind explicit checks. Keys that can move funds or upgrade contracts never live in frontend env vars.
  • Public RPC and API endpoints get rate limits so a script cannot bury you or your users.
  • Backend signers use a real key management setup, not a JSON file on a laptop.

User experience

  • Onboarding copy says that a wallet is required and which network to pick. Assume first-time users.
  • Pending states show that something is in flight, and confirmed states show when it is safe to refresh or navigate away.
  • Unsupported wallets or chains get a helpful message, not a blank screen.

Operations

  • Monitoring covers contract events, indexer health, and API errors. Someone gets paged when the chain RPC or your backend falls over.
  • Runbooks exist for pausing, upgrading, or responding to an incident. Panic is easier when the steps are written down.

We help teams review architecture and UX before launch. If you want a second pair of eyes, that is what we are here for.


Cogent Softwares, Web3 and AI development.