UX · Product Design · Case Study
Depinsim
Product designer
May 2024 – Jan 2026
Telegram · iOS / Android
1.2M MAU
Built from 0 to 1. Then upgraded.
DePINSIM went from a Telegram mini app to a multi-platform ecosystem. This case study follows that journey honestly — what we shipped first, what we learned, and what changed in version two.
The constraint
The real challenge wasn't technical — it was human. How do you make a product built on a complex decentralised protocol feel like something a traveller installs at the airport, not something a crypto developer configures on a weekend.
Timeline
May 2024 — V1 launched on Telegram.
Aug 2024 — V2 added engagement loops, partner campaigns, and a VIP system — extending compatibility to Line mini app and native app.
01
Research
Define the problem
02
Version 1
Ship the
core loop
03
V1
Decisions
5 keys
choices
04
Problems
found
What broke
05
Version 2
4 upgrade
decisions
06
Outcomes
What changed
Research
What we knew before building
User feedback, competitor analysis, and early product flow testing shaped three insights that directly changed what got designed.
User Personas
Travellers, remote workers, and Web3 enthusiasts who need seamless cross-border connectivity and a simple way to earn and redeem mobile data rewards.
Competitor Analysis
Most competitors focus on either global eSIM access or Web3 incentives — few connect connectivity, rewards, data utility, and gamified engagement into one continuous experience.
Make mobile data accessible, earnable, useful, and engaging.
From research to direction
Storyboard
The storyboard centred on frequent travellers needing affordable cross-border data — someone who wants to activate an eSIM instantly without swapping physical SIMs, earn rewards through participation, and convert those rewards into real mobile data. This reframed the entry point: the product had to answer "can I use this now?" before "what is DePIN?"
App map
Mapping the protocol's layers — eSIM, rewards, tasks, mined data, campaigns, wallet, profile — onto five branches (Earn / eSIM / Market / Airdrop / Profile) showed where the complexity could live without surfacing the underlying protocol to the user. This became the four-tab navigation that shipped in V1.
Problems to
solve for V1
What research told us to design for
Four problems, drawn directly from the persona, competitor gap, and storyboard above — each one a question the first version had to answer.
Pain Points
01
A crypto earn mechanic needs to be understood instantly
Sofia doesn't know what "mined data" means. Whatever the first interaction is, it has to teach the loop without requiring the user to read anything first.
02
Earned rewards risk becoming abstract Web3 points that never resolve into anything real
Most Web3 products reward users with points or tokens that stay abstract — numbers that accumulate but never convert into something tangible. If DePINSIM's earn mechanics follow that pattern, the product inherits Web3's core trust problem: rewards that don't mean anything.
03
Travel needs to feel like more than a number
The storyboard's core scenario is a traveller crossing borders. A distance counter doesn't capture that — the product needed to make movement itself feel rewarding.
04
A working eSIM doesn't activate itself
The eSIM delivers real value once turned on — but with no usage history yet, there's nothing pulling a user toward that first tap. Whatever drives activation has to create urgency where none exists naturally.
05
Growth couldn't rely on DePINSIM's budget alone
Acquiring users at scale meant funding rewards for every action — but a single company's budget caps how fast that can grow. The product needed a way to let outside money drive user growth without becoming an ad platform.
1.2M
Monthly active users
10K+
eSIM activations
$50K+
Revenue from data sales
10+
Enterprise integrations
Fast growth👏🏻 👏🏻 ! But ⚠️ the ~0.8% activation rate (10K installs from 1.2M users) revealed that most users arrived, earned a bit, and left without converting. The task list was completable in one session — and after that, there was nothing designed to bring them back.
What the data and users told us
Real usage revealed gaps that research alone couldn't have predicted.
01
Passive earnings went unnoticed without any prompt to check them
The eSIM kept mining even when users were away, but nothing surfaced what had accumulated. Users simply forgot the passive income existed — a mechanic built to reward absence only works if something brings them back to look.
02
Growth was self-contained, with no connection to the wider Web3 ecosystem
DePINSIM had no presence in other projects' user bases, and no other project had a presence in DePINSIM. Every new user came through DePINSIM's own channels — there was no mechanism to exchange traffic with partners who had audiences of their own.
03
VIP subscriptions underperformed despite being the product's key revenue line
VIP is the primary revenue stream beyond data sales, but subscription numbers fell short of target. The product wasn't short on people who could convert — it was short on moments inside the app that made VIP visible enough to consider.
The product existed in the real world
Rollup banners
Designed to work in dark conference environments — high contrast, product screens readable at 2m.
Physical SIM packaging
Dark background, space-themed visual language consistent with the app. The product's first tangible touchpoint.
Business cards + merch
Logo-first, minimal copy. The same visual language carried from app to object.
What I'd do differently
Shipping V1 before everything was resolved was the right call — but it meant offline visibility, VIP exposure, and partner integration all needed rework once real usage showed the gaps. I'd track how many users forgot the miner was running within week one, rather than finding out months later.
Some of the activation gap isn't fixable in the interface. Some devices can't run an eSIM at all — a hardware limit outside the product's control. And for many users, data abroad is seasonal: needed for a trip, not a daily habit. The product assumes continuous engagement; a real share of its audience only has an on/off relationship with it. That's a gap in the business model, not the design.
Related Projects
