Built. Tested. Shelved. Lessons from a self-custodial consumer app
Jan Albers & Florent Bartoli
What we built, and why
Over the past months, the two of us designed, built, and tested a consumer app at the Safe Ecosystem Foundation, for people who hold crypto but do not trust their own setup. Few people know it existed, which was a deliberate choice: we wanted to learn before announcing anything. We have since shelved this iteration. What we're sharing here are the learnings from building it, which felt more useful in the open than left in our archive.
The people we built for sit between two bad options. Hot wallets are convenient but one signature or one lost phone away from disaster. Safe multisig setups hold up, but carry an operational overhead which didn't match the experience participants of our research were looking for. In between sits a significant group of people, especially crypto native ones, who know their setup is inadequate and have not fixed it, often for years. We wanted to answer one question: can you give these people a neobank-grade experience that stays true to self-custody, without putting a bank or custodian in the middle?
What we built: a native iOS app built on the Safe smart account. A co-signer checks every transaction against rules the user sets before it goes through. Recovery works through a physical NFC card by Keycard instead of a seed phrase. Gas never surfaces for the user. Saving, investing, and spending live in one place.
What we heard from users
Before writing product code we spent the early months talking to users: structured discovery interviews, solution interviews, and moderated testing sessions on a prototype. Three problems dominated:
People sign transactions they cannot read. Above 90 percent of participants routinely approved transactions they could not verify. This included people with a decade of daily onchain experience, and some of the most experienced had been phished anyway. Nothing else we found was this acute.
Recovery is broken, and everyone knows it. Nearly every participant had a fragile recovery setup, was aware of it, and had not fixed it. Often the gap between knowing and acting was years old. This was the most widespread pain by far.
Crypto holdings scatter. Assets spread across wallets, and people carry a constant anxiety about what is where.
What was most surprising to us is that these are not new issues, but that ten years into Ethereum's existence even the most sophisticated users had not found a setup they were satisfied with, and that the missing pieces are still hygiene factors.
Beyond the big three, the following insights shaped what we built:
Savings is the entry point, and adoption is additive. Across every segment we tested, people responded to a savings framing before anything else. And few migrate existing balances into a new product. They route their next deposit to it, watch what happens, and escalate as trust builds. If your pitch is consolidation, it shouldn't build on migrating funds from the start.
Recovery is the precondition for deposits. Without a recovery story the user finds credible and can understand, no money moves. Closely related: users want rules they can set themselves. Limits, delays, and pre-approvals within sensible presets were the single most requested security capability, and nobody rejected the principle. People asked to adjust the thresholds to their own situation. This is part of a larger theme we noticed: participants want barriers and friction. However, the friction that crypto has right now (e.g. connecting your wallet to a dapp, updating the firmware of a hardware wallet) is not beneficial, quite the opposite.
A backup keycard builds more trust than we expected, especially because it was physical and could be held in hand. It resonated most with people who carry seed phrase anxiety, and produced some of the strongest individual reactions we recorded in testing. However, it also created friction points in the beginning. We started with three cards, which was perceived as a burden by participants. Reducing it to two, one primary and one backup card, was closer to the sweet spot.
Borrowing is wanted and misunderstood at the same time. Participants told us unprompted that they would rather borrow against their assets than sell them. Then most of them stood at our borrow screen and could not work out what was happening. Lending is one of DeFi's largest categories, yet even experienced users have a limited grasp of borrowing against their own assets. The industry has an education gap here.
How we addressed it
The account is a 2-of-3 Safe smart account: an embedded wallet, a co-signing service, and a passkey on the user's device. The co-signer checks every transaction against a recipient allowlist, a contract allowlist, function allowlist, and spending limits the user has set, and only then adds its signature. Users never see it working. It only becomes visible when a transfer to an unknown address or an interaction with an unknown contract gets blocked.
Recovery became a physical NFC card kit, registered as a guardian onchain. Within a few weeks of iteration, recovery comprehension went from our top friction point to a solved problem. Once the flow explained why each step existed, users picked up the unfamiliar model quickly.
Safety limits came straight from the rules finding. Inside your limits, transactions sign normally. Above a limit, the app asks for Face ID. For the largest movements, the design adds a time delay. This puts friction where the user decided it should be.
While building we always set for ourselves the goal to remove single points of failure. No signer was dependent on the other signers (passkey on device, embedded wallet by Privy, co-signer by us), the recovery was independent of all signers through the NFC card, and the co-signer that we ran could always be overridden by the user given the Safe's 2-of-3 configuration.
We reused pieces that exist in the ecosystem: hardware from Keycard for NFC cards, the social recovery module from Candide, swaps through CoW Protocol, embedded keys from Privy, gas abstraction through Pimlico, fiat rails with Monerium.
Build velocity
This was fast, and it was not vibe-coded. The two of us built everything, and only one of us writes code.
When we needed user feedback on flows, Jan, who is not a developer, built a front-end-only prototype with AI assistance and put it in front of users. We ran every testing session on that prototype, and could do fast adjustments to a flow between sessions. That let us iterate against real user feedback faster.
Once the concept was locked, the native app took one to two months from idea to a stable iOS alpha through TestFlight. AI assistance ran through every stage, from the research analysis pipeline to implementation. The method might warrant its own article.
The short version: building a real product on real architecture is easy now. What to build, how to distribute it, and how to navigate regulation are what's hard.
Day to day, it changed where Florent's hours went. Where it used to be fighting with “not always up to date” documentation and the quirks of many SDKs and languages, AI allowed him to focus on the actual building: architecture, security, testing, and automation.
Hence, by setting strong guardrails for AI, most weeks, our time went into shaping the product together.
Where we ended up
We shelved this iteration before external user funds ever touched it. We set that bar for ourselves deliberately. A few things shaped the call for us:
Self-custody hygiene, meaning recovery, comprehension, and limits, is necessary. So is gas sponsorship. However, our read is that it's not enough on its own to make a consumer product engaging. Current DeFi yields compete poorly with what fintechs and banks pay, which weakens the savings wedge right where users respond to it. The industry's security incident rate keeps the cost of any mistake with user funds unacceptably high. Even in the roughly one month during which we tested with real, but sponsored, funds, two major incidents happened: one for a lending protocol that was seriously considered for integration, the other around smart contracts we considered using. On top of that, the direction we believe in most, closing the borrowing loop, carries regulatory weight that a foundation-incubated experiment is the wrong vehicle for.
None of this is a verdict on consumer self-custody. We would build for everyday users again when crypto can beat centralized finance at something that matters to them beyond self-custody itself. We have a view on what that something is.
What we believe can work
The most untapped opportunity we see in consumer crypto is borrowing: the loop between buying assets, borrowing against them, and spending the liquidity. Users brought it up unprompted, the primitives exist onchain, and nearly every product in the industry still breaks the loop somewhere.
To be precise, for us this is a thesis, one we intend to carry into future thinking as well as Safe Ventures. Our research surfaced the demand signal, but it also showed a significant education gap: when participants gave feedback on the UI and UX through several iterations, the borrowing flow remained the one with the most question marks, despite borrowing against one's assets being an unprompted wish that surfaced throughout every iteration of this project. That also means today's visible demand is a floor. The hardest part is not technical: consumer credit is heavily regulated nearly everywhere, so a team that solves compliance properly, not only by avoiding enforcement, will have a significant edge.
The second direction is trust-minimized middleware. Our optional co-signer worked, and users never had to think about it. It was also a centralized service, and onchain systems should not depend on one trusted server. A decentralized layer, enforcing the user's rules without a single operator to trust or compromise, is infrastructure the ecosystem needs, and one we wish had been established tech already.
If you are building in this space, three things read to us as table stakes: recovery your users can rehearse and understand, a next-deposit wedge rather than a migration pitch, and security controls the user understands and applies.
The gap for experimentation
This section is our view as authors, not a legal analysis.
In Europe, a team that wants to test a compliant consumer product in this space faces licensing costs and timelines that can exceed the resources of the team itself, before anyone has proven that users want the product. The practical alternatives are worse: build where enforcement is unlikely, or design the product around not getting caught. So the rules end up selecting against the builders who take them seriously.
What is missing is a graduation path: somewhere to test with real users at limited scale, prove a business case, and grow into full compliance instead of needing it on day one. Sandbox regimes exist elsewhere in finance; nothing comparable fits products like this one.
What happens with these learnings
The recovery model, the co-signer learnings, and the research flow back into the Safe ecosystem, and some of them may resurface in Safe products. Some of them, we hope, resurface in yours. If you are building recovery, policy layers, or a borrowing experience and want to compare notes, reach out to either of us.
Jan Albers: @jan_lbrs · Florent Bartoli: @FloB_Safe
Share this
