The product was fragmenting because the org was
Authentication had been rebuilt four times.
On-Ramp had its own version. Off-Ramp had another. The consumer app's login was a third. NFT Checkout had a fourth. Same capability, four implementations, maintained separately, improved in isolation.
Auth was the most visible example. The same pattern ran underneath the whole product. Identity. Payment methods. Wallet logic. Trade configuration. Every new feature rebuilt the primitives it needed instead of composing from shared infrastructure — because the primitives weren't owned as shared infrastructure. They were owned inside whichever team happened to ship them first.
MoonPay's product in 2023 was the engine that processed most of the world's crypto on-ramp volume — ~$1.5B in annual TTV at the time, growing past $2B by 2025. Profound product-market fit. And fragmenting under the weight of its own success.
The fragmentation wasn't a tech-debt problem. It was an ownership problem. Every team owned every capability inside their product, instead of any team owning those capabilities as shared infrastructure. Cowboy mentality dressed up as autonomy.
When every new product rebuilds the same primitives, the issue isn't quality control. It's an architecture misaligned with how capabilities relate. Monolithic products produce monolithic teams, which produce monolithic thinking. You can't fix one without fixing the others.
That was the problem I set out to rebuild.
Atomic design, at the wrong altitude
I'd been watching the same thing happen across every team. Everything we'd built was a permutation of the same few capabilities.
Authentication. Identity. Payment methods. Wallet infrastructure. Trade configuration. Fraud. Order tracking.
An Off-Ramp was almost exactly an On-Ramp with the asset delivery inverted. An NFT Checkout was Buy with a different asset class. Airdrops required auth + KYC + wallet infrastructure — we had all of it, but we rebuilt it every time.
The company was thinking in monoliths, not modules.
Atomic design isn't only a UI pattern. It's a way to organise anything that scales. Apply it at one altitude, you get a design system. Apply it at the capability layer, you get a new product architecture. Apply it at the team layer, you get a new operating model.
Atom
A single token — a colour, a spacing value, an icon.
The same architecture should answer three questions simultaneously: how does design organise? how does code organise? how does the org organise? If any diverge, you haven't systematised. You've moved the problem.
Getting it on paper
In June 2023, at an offsite in Lisbon, the VP of Product pulled me aside. He wanted to do something radical — he'd been feeling the same drift and duplicated work I had, and he knew the next move was bigger than a cleanup. He was looking for the frame.
I'd been triaging the fragmentation for months. What he framed as a redesign needed something else underneath it first — a different way of organising ownership. I pulled him into a room and drew it on a piece of paper.
Every capability rebuilt as a module, one team per capability, full ownership. Modules chained into product flows — no forks. Auth, Payments, Identity, Wallets, Trade, all on the same pattern. The org structured around capabilities, not products.
We roped in the VP of Engineering. He'd been carrying the cost of fragmentation longer than anyone — every duplicate build was tech debt absorbed, every divergence a maintenance tax. A product designer talking about modular ownership was a conversation he'd been waiting for someone in design to start.
By the end of the afternoon, three of us were aligned — one sensing the drift, one absorbing the cost, one drawing the frame.
The bet took hold.
Proving the pattern with Auth, then Buy
Beyond the room, the pattern needed proof in practice. I used Authentication as the example — four rebuilds deep, highest-leverage cleanup, cleanest module to isolate, and the one everyone felt the pain of. But Auth wasn't the goal. It was the proof that any capability could be redesigned this way.
Inspired by Sign in with Apple, I designed auth as a half-sheet experience on top of the product that triggered it. Two UX systems in tandem. Interstitial, micro, a means to an end. Not a linear flow. Not full-screen. Something the user barely noticed.
The demo came next: a returning-user Buy composed from the modular blocks. Entry point from a token view — we already knew the currency, so no selection. Already signed in — no auth. Apple Pay on device — no payment selection.
What remained: enter the amount, Face ID.
Two taps. Two views.
The CPO said it was the most impressive lift to the ramps product he'd ever seen.
Selling it as MoonPay 2.0
December 2023. I presented to the entire 300+ person company.
Not a design deck. An operating-model proposal. Complete modular product architecture. New team structure. One capability-aligned team per module. Full ownership, no forks, composition as the default.
We called it MoonPay 2.0.
The CEO was ecstatic. Product, Engineering, and Design aligned.
2024 commenced, guns blazing.
Re-architecting the org
The first thing 2024 got was a new name: MEG — the MoonPay Experience Group.
The restructure wasn't a reorg. It was an identity shift. You could see the operating-model change in the org chart.
- XP — a new team founded to own the design system and orchestration
- Module-aligned squads for Auth, Payments, Identity, Wallets, Trade — each owning their full stack, front to back
- The old widget team became the new Trade team, responsible for composition and the quality bar across modules
- Platform kept doing backend work, with clearer handoff contracts
The rename from Widget to Trade wasn't cosmetic. "Widget" meant everything and therefore nothing — anything could be a widget, and everything had been. "Trade" gave the team a specific capability to own: configuration, setup, order tracking, composition quality. Scope became legible. The rename was the org change, named.
Each squad had its own PM. Paolo and I oversaw design across the blocks.
The business was running three massive initiatives in parallel: Blocks, a consumer app redesign, and Fiat Balances. Half the design team was absorbed by consumer exploration — going in circles without a construct. Paolo and I were the only two who could commit to Blocks full-time. He took Auth, I took Identity, with the plan to pick up Wallets, Payments, and the Trade flows next.
But I'd inadvertently empowered a monster to create a monster. The entire PED org was restructured simultaneously. We had to keep the old engine running while building the new one. Payments teams were mid-flight on PayPal for the old stack; the new stack was quarters away. Duplicate work for a while.
In April 2024, I made the call that protected Blocks. The consumer team was spinning its wheels — three designers without a clear construct, designing the home screen in high fidelity without a structural foundation. Blocks needed focus.
I didn't argue for stopping consumer. I argued for sequencing. I proposed pulling the consumer designers onto Blocks for a quarter — focus one huge product area, then return to consumer with a unified structural base. The VP of Product agreed. By end of June, we were design-complete on the entire Blocks infrastructure.
Meanwhile, Fiat Balances ramped up from a quick win to a multi-quarter priority — the business cared more than it admitted publicly. I absorbed it onto my own plate so Paolo could stay on Blocks as IC lead. Months of dual-tracking. If I hadn't taken it on, the business's most important initiative at that moment would have slipped.
I held a private doubt the whole time. MoonPay treated every launch as a theatrical product reveal, and Blocks got framed the same way. But Blocks was infrastructure work — invisible to customers, with a payoff that would compound over years rather than land in a moment. I kept having to remind myself, and the team, that the quieter version of success was still success.
The architecture compounded
Blocks didn't prove itself in the pitch or the demo. It proved itself in the velocity curve between successive launches.
On-Ramp
~3 quartersOff-Ramp
~1 monthFeature extension
~1 sprintOn-Ramp took ~3 quarters from scratch.
Off-Ramp took less than a month — every module already reusable. The novel delta (asset delivery + flow-of-funds inversion) was the only new work.
A feature extension — adding deposits to the Payment Method block — took one sprint. Everything else already existed.
Each subsequent launch was cheaper than the last. The architecture didn't just enable strategy — it compounded it. The bet I'd drawn on paper in Lisbon — modularity as an operating-model change, not a design one — was proving itself in the velocity curve.
Orion Buy launched to customers in December 2024 with Trust Wallet and bitcoin.com as first design partners. Thirteen months from the pitch to the full vision live.
In Q1 2025, technical refinement drove On-Ramp conversion up ~20% in some markets. Architectural cleanup turned into direct business impact.
None of this happened without Paolo. He carried the IC work across block teams under real pressure while I was absorbed by Fiat Balances. If he hadn't held that line, Blocks would have fallen over.
The architecture is still in place. The modules still run MoonPay. The operating model survived subsequent leadership changes and my own exit. Design systems get rewritten. Operating models persist.
What the modules unlocked
Compounding velocity was half the payoff. The other half was that each module could now be improved in isolation — without coordinating with every other surface that used it.
Authentication. Once Auth was its own module, we stopped seeing duplicate account creation as "users failing the funnel" and started seeing it as a correctness problem. We tuned retry logic, consolidated sign-in surfaces, fixed the corner cases that only one of the four prior implementations had ever gotten right. Duplicate account creation fell 30% in two quarters.
Identity. When Identity became independent of transactions, we could trigger it outside the transaction flow entirely. We reframed the whole pattern as "spend readiness" — customers verified their identity to raise their spending limit, not to complete a purchase. The pressure of a stalled transaction disappeared. KYC pass rates lifted 15%.
The second unlock was for our highest-spend customers. EDD queues had backed up at two months — high-value users stuck for weeks before raising their limits. With Identity modular and independent, we improved the EDD submission flow directly. Lead times dropped from 2 months to under 48 hours.
Cross-ramp consistency. Before Blocks, every new ramp shipped with its own design-language drift. Post-Blocks, every ramp shared one engine and one design system. Sends — shipped months after the Blocks foundation — came out visually and behaviourally aligned with every other ramp by default. Consistency became a structural property, not a design-review checklist.
None of these wins were Blocks. They were what Blocks made possible.
What I'd do differently
I'd treat it as an infrastructure play, not a product reinvention. We sold Blocks as a company-wide, high-visibility product reveal. The healthier version would have been an incremental infrastructure rollout — injecting new components into the old stack piece by piece, with a product-launch moment at the end. The big-bang framing created sequencing constraints that cost us time.
I killed the Shell in 2025. The half-sheet form factor was buttery on iOS — but React Native couldn't replicate the motion on Android. What felt seamless on iOS felt jarring on Android, especially in longer flows like KYC. We explored alternatives for months before abandoning the compact form factor. I'd have stress-tested cross-platform parity earlier, before anchoring the team on a motion-dependent pattern.
I underinvested in partner integration. The micro-pattern vision assumed we controlled the frame. Most partners used iframes, which meant full-screen, which meant the Shell magic was invisible. Partners were happy — conversion improved, the product looked cleaner — but the vision we'd pitched was for consumer, not for them. I'd scope partner testing into sprint 1 next time, not sprint 40.
The principle
You can't re-architect a product without re-architecting the org.
The fragmentation in MoonPay's product wasn't a tech-debt problem. It was an ownership problem. Rebuilding the code without rebuilding the ownership would have produced the same mess a year later. The real work was re-architecting MEG so each capability had an owner — and then letting the product architecture follow.
The design-system lineage gave the move an easy entry point for non-design leaders. But the change was organisational. Years on, the operating model is the thing that's still running.
