A dashboard inside a dashboard

Stripe invited Mercury into the alpha for a new kind of Stripe App: a full-page, multi-view experience that could live inside the Stripe Dashboard. Instead of a narrow utility tucked beside a payment, we could bring the shape of Mercury into Stripe — balances, accounts, transactions, and the actions that move money.

The opportunity was strategic as much as functional. Mercury and Stripe already shared a large startup audience, and Stripe Atlas was moving closer to business banking. A useful Mercury surface inside Stripe could deepen that partnership while putting Mercury in front of founders where they already ran their revenue.

We had four weeks. The team was one engineer, one PM, and me as the sole designer.

Designing without the kit

The platform was still emerging beneath us. We had early API access, but no complete Figma library for the new full-page layout. I pulled together Stripe's public design resources, studied existing Dashboard apps, and reverse-engineered UI primitives from API documentation shared in Slack. Even then, the API changed as we moved toward launch.

The hardest part was live-translating between two design system paradigms. Stripe had its own components, density, and interaction patterns. Mercury had established ways of rendering Accounts, Transactions, balances, and actions. The app needed to feel native to Stripe without turning Mercury into a stranger.

That made implementation review part of design. I stayed close to engineering output, checking that each screen used Stripe's system consistently while preserving the hierarchy and clarity customers expected from Mercury.

Code as a design tool

Static mockups could only take us so far because the layout primitives themselves were new. I used Claude to stand up working code in Stripe's API sandbox, connecting the new full-page framework to our existing API calls. I could modify layouts, see where the system bent or broke, and give engineering something real to react to.

The prototypes were not a handoff artifact. They were how I learned the medium. By testing live components instead of approximating them in Figma, I helped the team understand which layouts were possible and shaped the final specification around what the platform could actually support.

The connection from both sides

The experience started before the Stripe Dashboard loaded. On the Mercury side, customers reviewed the account data the app requested and explicitly authorized the connection. That handoff had to make a new integration feel understandable and controlled, then return customers to an app that already felt at home.

The confirmation email completed the loop. It named what had connected, summarized what the app could see, and gave customers a direct path to manage or remove the integration. The connection was not a one-time consent screen; it stayed legible after the moment passed.

Inside Stripe, we carried Mercury's information architecture across tabs for the overview, transactions, accounts, and connection settings. The result was not a miniature Mercury website. It was a translation: the right Mercury workflows, expressed through Stripe's interface.

Designing the growth paths

The app also had to work for people who did not yet have Mercury. The Settings view explained the broader product, linked to a live demo, and gave new customers a direct signup path alongside sign-in. Those moments turned an integration screen into a product-discovery surface without getting in the way of existing customers.

I designed the launch assets for the Stripe App Marketplace, carrying the same story into three frames: move Stripe revenue to Mercury in minutes, run the business from Mercury, and watch the balance update inside Stripe.

Mercury for Stripe launched at Stripe Sessions in April 2026 as one of the alpha partners showing what full-page Stripe Apps could become. We shipped while the platform was still changing, without the normal design kit or process. Working code closed that gap — and gave design a way to lead through it.