Wallet flows and on-chain UX that survives the unhappy path

Web3 product interfaces

Marketplaces, minting, and wallet-connect UX designed around failure — pending transactions, rejections, wrong network, gas spikes.

All services

Overview

Web3 interfaces live or die on the unhappy path. The happy path — connect, sign, done — is easy. What separates a product that people trust from one they abandon is how it handles a rejected signature, a stuck transaction, the wrong network, an expired approval, or an RPC that goes quiet.

I build these interfaces with the failure states designed first, the on-chain reads and writes typed properly, and language that tells a non-expert user what is actually happening without lying to them.

What ships

  • Wallet connection UX: multi-wallet support, network switching, account changes, and reconnection handled without a full reload
  • Transaction lifecycle UI: pending, confirmed, replaced, failed and dropped — each with a clear next step
  • Typed contract layer in TypeScript using viem or ethers, with reads, writes, and simulation before send
  • Minting, marketplace and approval flows with gas-aware messaging and sensible defaults
  • Indexed data wired into the UI — a subgraph, an indexer, or event logs — so the interface is not waiting on chain reads
  • Security-minded patterns for approvals, signatures and spend limits, with copy that explains the risk

A good fit when

  • Users drop off at wallet connect or at the first transaction
  • Your app breaks when someone switches network or account mid-session
  • Transaction feedback is a spinner and a hope
  • You have solid contracts and a front end that does not do them justice

FAQ

Do you write smart contracts?
I read Solidity well enough to integrate against it confidently and to catch interface mismatches early, but contract authoring and audits are best left to specialists. I work alongside them.
Which chains have you worked with?
Mostly EVM chains — Ethereum mainnet and the common L2s. The interface patterns transfer; the differences are mostly RPC behaviour, finality, and gas UX.
Can you make the technical parts understandable to normal users?
That is most of the job. I write the transaction and approval copy myself and test it on people who do not think in nonces.

Tell me about your product

Share a short brief — problem, timeline, and stack — and I'll reply with a candid view on fit, effort, and the fastest path to a shippable milestone.