How to Architect a Production dApp
A production dApp is three systems, not one: smart contracts, indexers, and the application itself. Most teams over-invest in the contracts and discover — usually the week before launch — that reading chain state at product speed is its own engineering discipline.
Start with the state that must live on-chain. Settlement balances, ownership records, permissions: these belong in contracts. Everything else — search, sorting, history, analytics — belongs in an indexer fed by well-designed events. If your events can't rebuild your product's state, your events are wrong.
Design events as if they were a public API, because they are. Indexers, analytics, partner integrations and your own future frontend will all consume them. Emit state transitions, not just endpoints: "position opened" is useful, but "position opened with collateral, entry price and expiry" is what keeps you from re-querying history forever.
Wallet flows deserve the same rigor as contract logic. Connection, signing, pending and failure are four distinct states, each with its own UI, timeout and recovery path. On Vaultline we measured a 3.4x onboarding improvement purely from treating these states as designed product, not edge cases.
Finally, rehearse the launch. Deploy to a fork, run the full user journey, simulate reorgs and RPC failures, verify constructor arguments and permissions on-chain. Our pre-mainnet checklist runs to forty items — boring, repeatable, and the reason our launches are uneventful.
Related Articles
Smart Contract Development: What Happens Before Deployment →