Shipping dApps: EVM vs Internet Computer

Notes from building on both EVM and ICP across five hackathons — where each shines and where the rough edges live.

#web3 · #icp · #evm · #solidity · #motoko

I've shipped hackathon dApps on both EVM (Solidity, Hardhat, Ethers.js) and the Internet Computer (Motoko canisters). They're very different beasts. Here's a quick field guide based on what I learned in the trenches.

Mental model

EVM        →  Stateless contracts + external indexers + wallet UX
ICP        →  Stateful canisters that ARE the backend + frontend assets

On EVM, your smart contract is a thin slice of state that the world reads through nodes and indexers. On ICP, a canister can hold gigabytes of state, serve HTTP, and host your frontend assets — it really is a "full backend on-chain."

Where EVM wins

Ecosystem depth. Tooling (Hardhat, Foundry), libraries (OpenZeppelin), and oracles are mature.
Wallet UX. MetaMask + WalletConnect is well-understood by users.
Composability. ERC-20, ERC-721, and DeFi primitives are battle-tested.

Where ICP wins

Cost model. Reverse gas — users don't pay per call.
Backend feel. Canisters feel like writing normal services in Motoko, not like writing math problems.
Web2-style UX. No wallet prompts for every action.

The bullet points I wish someone told me

Start with the UX. Pick the chain that fits the interaction model you want, not the other way around.
Read the gas table. EVM gas costs will shape your data design more than you think.
Don't over-engineer canisters. Stable structures and upgrade hooks are powerful but easy to misuse.
Plan your indexer early. On EVM, you'll need one. Decide between The Graph, custom GraphQL, or direct RPC calls before you're 80% done.

More deep dives coming on each of these.