Mike Demarais almost did not build Rainbow.
He had been using crypto wallets for years. He understood the technology. He also found the experience consistently, specifically terrible — not in an abstract way, but in the I cannot get my mother to do this, the interface is the problem way.
That frustration is where Rainbow started. Not from a technical insight. From a user experience that was so broken that someone with the skills to fix it decided they had to.
The pattern repeats across almost every reference product in the space.
The frustrated-user origin
What Phantom's founders experienced before building
Francesco Agosti and Chris Kalani were not new to design when they joined Phantom. They had worked on consumer products at companies that took UX seriously.
When they encountered MetaMask — the dominant Solana wallet at the time did not yet exist — they saw something familiar from their previous careers: a technically functional product designed by people who assumed the user shared the builder's knowledge.
The founding insight was not novel. It was the same insight that produced every consumer product that simplified a professional tool:
The person using this is not the person who built this.
Argent's founding frustration
Itamar Lesuisse and Gerald Goldstein built Argent after experiencing what most crypto newcomers experience: the combination of seed phrase management, gas estimation, and transaction signing that makes self-custody feel like a job.
Lesuisse has described the founding of Argent in terms of a specific failure mode: smart people who understood the technology still found self-custody too risky to use for real money. Not too complex. Too risky. The interface was not adequate for the stakes.
That is a different problem than most crypto teams think they are solving.
The counterargument: crypto-native founders built real things too
Hayden Adams coded Uniswap alone over six months before launch. He was not a frustrated outsider — he was a mechanical engineer who had never written Solidity and decided to learn it by building a DEX.
Synthetix was built by Kain Warwick, a payments entrepreneur who understood DeFi mechanics deeply. The protocol is technically sophisticated in ways that require genuine crypto expertise to produce.
The counterargument: outsider frustration is not sufficient for great product design. It is necessary.
Adams built a simple interface because he was building for himself — a smart person who wanted to swap tokens without the friction of existing DEXes. He had the outsider's desire for simplicity and enough crypto knowledge to know what had to stay. That combination — frustration plus competence — is the actual pattern.
The founders who built bad products also came from the outside. The difference was not outside vs. inside. It was whether the frustration was specific.
What specific frustration produces that vague frustration does not
Most crypto product teams have a general sense that their UX "needs work." That is not the same as the frustration that built Rainbow.
| Vague frustration | Specific frustration |
|---|---|
| "Onboarding is too complicated" | "My co-founder, who has a PhD, could not complete a deposit without my help" |
| "Users don't understand gas" | "I watched three people abandon the same transaction at the same gas estimation screen" |
| "The interface feels technical" | "Every wallet looks like it was designed for someone who already understands what they're doing" |
| "We need to improve UX" | "This specific flow loses users because this specific thing is not explained" |
Vague frustration produces redesigns. Specific frustration produces products.
Demarais did not decide Rainbow should be "more enjoyable." He identified that existing wallets optimized for functionality over experience, and that a significant segment of potential users — people who owned crypto but did not actively use it — would use it daily if it felt like a real consumer product.
That is a specific thesis. It produced specific design decisions.
Why crypto-native teams often miss this
There is a well-documented pattern in product design: the more familiar a team is with their own product, the less they can see what a new user sees.
In crypto, this problem is amplified.
Crypto-native teams have spent years developing intuitions that their users do not have:
- Gas is a cost of operating on a decentralized network
- Seed phrases exist because there is no password recovery
- Approval transactions are a security feature, not a bug
- Slippage tolerance is a normal parameter to adjust
These things are true. They are also invisible to most users.
The team that built these features does not see them as friction. They see them as correct behavior. Fixing them feels like misrepresenting how the technology works.
Stani Kulechov has acknowledged this tension directly: the people closest to DeFi protocols have the hardest time seeing them as a new user would. The distance required to see what is broken is the same distance that makes it hard to build what needed building.
The hiring implication
The pattern suggests a specific hiring heuristic that most Web3 teams apply in reverse.
Most teams hire for:
✅ Crypto knowledge
✅ DeFi experience
✅ Familiarity with Web3 tools
✅ Previous crypto product work
The frustrated-user pattern suggests also hiring for:
✅ Has been genuinely confused by crypto products (specific confusion)
✅ Has consumer product experience where UX parity was the standard
✅ Brings an expectation of interface quality that current products do not meet
✅ Can articulate exactly where an existing product fails and why
The best hire is not the designer who loves crypto. It is the designer who loves products — and finds the current state of crypto interfaces unacceptable.
That person will have standards the crypto-native designer cannot have, because the crypto-native designer has adjusted to what exists.
What this means for teams building now
Map your own frustrations specifically. Not "the UX is bad" but "I watched this specific thing happen to this specific person at this specific moment." Write it down. That is your product brief.
Hire the person who complains about your product. Not the person who tolerates it. The designer who says "I find this wallet unusable" is more valuable than the designer who says "it's fine once you understand it."
Treat unfamiliarity as research, not incompetence. When a new designer says "I don't understand why this step exists," that is not a gap to be filled with education. It is a design finding.
Calibrate your baseline to consumer products, not to crypto. Stripe, Linear, Revolut, Figma — these are the products your users compare your interface to. Not the other DeFi protocol from last quarter. The frustration gap between those products and yours is the exact size of your design opportunity.
Protect the outsider perspective as the team grows. The frustration that produced Rainbow will be harder to access as the Rainbow team becomes crypto-native. The same will happen to your team. Build a process that keeps the new user's experience visible — usability testing, external audits, hiring deliberately outside the space.
The best Web3 products were built by people who were frustrated enough with existing products to spend years rebuilding them.
That frustration was not a liability. It was the only design brief that mattered.
The question for every product team is whether they still have access to it.
I work as a Web3 creative director helping teams translate their founding frustration into products that don't require that frustration to use. somaryuu.xyz
