Buburuza

Audience

Businesses operating across both traditional and crypto rails — crypto-native companies (exchanges, funds, Web3 startups) that needed a bank account that felt legitimate and compliant, and more conventional SMBs that wanted crypto exposure without giving up standard fiat banking. Both groups were underserved by providers built for only one side of that split.

The Problem

Businesses touching crypto had two bad options: a traditional bank that treated any crypto activity as a risk to manage around — often freezing or closing accounts over it — or a crypto-native platform that could move digital assets but didn't feel, or function, like a real bank. Nobody had built a single product that combined the two convincingly.

Metrics

Buburuza was pre-launch, so there was no usage metric to chase — the only number that mattered was time-to-market. The team was racing established, well-funded competitors, so speed itself was the metric the business was optimizing for, and that pressure shaped every design decision below.

Research & Hypotheses

Scope wasn't set through a formal research phase — it came from a working hypothesis: that the fastest way to earn credibility was a tight "accounts + payments" core, with everything else (cards, investing, team permissions) deliberately deferred. That hypothesis wasn't validated ahead of time; it was tested by shipping and seeing whether the core alone was enough to function as a real product.

Problem

One designer, dozens of features, no time to hand-design each one.

Solution

Built a deliberately simple, reusable set of components and patterns — clear enough that engineers could assemble new features correctly.

Problem

A full KYC flow up front blocks access and stalls time-to-first-value.

Solution

Users complete the essentials, land in the product, and finish verification later from the dashboard.

Problem

Users need their financial position at a glance, across accounts, wallets, and transactions.

Solution

Kept deliberately simple — a foundation, not a finished destination — centered on one total money-movement view.

Problem

A full transaction log has a lot of possible states — pending, converting, failed, settled.

Solution

Built entirely on the existing state system used throughout the product — this screen, and any future one like it, could be assembled from existing components rather than designed from scratch.

Problem

Core money-movement flow, high stakes, easy to over-design.

Solution

Shrunk the sending and receiving flows down to no more than 3 screens each — just what's needed, nothing extra.

Problem

Buburuza spans both fiat and crypto rails, so adding a recipient isn't one form — it's several (bank details, wallet address, saved contact).

Solution

Built recipient entry as one reusable form pattern that adapts its fields to the selected rail.