Deep Dives

Designing in the open

The story of the Mercury demo
Mercury Demo UI

Jonathan is a software designer and writer based in Portland, Oregon.

March 16, 2026

The beginning

For many companies the decision to work with a new finance tool — whether a payroll provider, an expense tool, or a banking product — is incredibly significant. It’s a decision on core infrastructure that can shape the financial trajectory, outputs, and way that a company scales. 

Ryan Wiggins, Mercury’s VP of Product, relayed a conversation to me that he had with our CEO Immad Akhund about how strange they both found it that, often, when making these critical decisions, you don’t really get to see the product before you sign up to use it. 

They wondered: What would it be like to let everyone see our product before they made the choice to commit to it? 

When I joined Mercury as a product designer in late 2021 one of my first projects was to help us explore this question by launching our internal Mercury demo to the public. This is its story.

Working in the open

The origins of the work itself were pragmatic. Mercury had built an internal environment called Mock, where engineers could test live experiences by plugging variables into a URL to simulate different user states. This became the basis for a live demo that always reflected the current state of our product.

We knew it cut against convention, but showing the real product, unvarnished, felt right. It meant giving our potential customers something true that they could rarely access without signing up for something, and, hopefully, equipping them with genuine insights to help them make their choices, whatever their needs were. Mercury was purpose-built for startups, but we’ve long welcomed a wide array of businesses and industries on board, each with unique needs in addition to the priorities they share in common.

We recognized the approach had risks — showing the warts, the things that we might be fine-tuning, or were in their first public iteration; contending with the reality that many demos showed a more idealized take on products; making something available to anyone to try, screenshot, copy.

But we weren’t (and aren’t) selling an idealized version of our product; we are selling what it is. We felt that any signal on resonance was valuable and that prioritizing the needs and agency of potential users was big enough to outweigh any skepticism. So we proceeded. 

From there, the constraints felt minimal. We’d decided to let it all hang out, so we doubled down: a fully public demo, no contact info required, no gates.

Letting the product speak for itself

Once the demo was live, we quickly saw its impact both internally and externally.

Externally, an ungated demo, we learned, can become a very busy place. We figured we would get some traction, but were surprised by the sheer number of people actively engaging when there was nothing to get in their way. And, from day 1, we saw a change in how quickly people were moving through the funnel and into the product. 

More people trying the product also meant more people talking to Sales — but the conversations were taking a new shape. As Nick Dellis, Mercury’s VP of Revenue, shared, “Founders were suddenly coming into conversations already knowing that Mercury could handle their specific use case. Instead of walking through basic features, we could jump straight into the nuanced questions about their business — something I viewed as a better and higher signal use of their time.”

Beyond that, we also learned that seeing the real-deal product gave people more confidence to make independent decisions about whether Mercury was a fit for them. As Wiggins recounts, “One day about a year in, someone discovered the demo, chose to use Mercury, signed up a great business, and just… deposited $50 million, totally independently.” Wild times!

Internally, having the demo open this way encouraged our product teams to go deeper on the interface, keep laser-focused on user needs, and hone the details even more proactively. That paired with a “ship fast and learn” mindset has led to entirely new Mercury features built from the ground up like recipient invites, SAFEs, and downloadable formation docs.

Unexpected constituencies

The demo has been live and evolving alongside our product for a few years now — and over time we’ve also seen it impact some unexpected aspects of Mercury’s business.  

Because it allows for the product to be out there live and real and available, we’ve found that many candidates reference the demo before their interviews. (Others have shared that it actually piqued their interest in working at Mercury, as they could get a true sense of what they were potentially signing themselves up to help build!)

We’ve also seen regulators use it to understand our product, giving them easy access to what shows up where and when, what it’s like to make a payment, and more. Our compliance and policy teams have even had occasion to share the demo with policymakers.

Ultimately, all of these demo users face a similar challenge as founders and business owners evaluating a new financial tool: how do you understand what you’re really working with? And how do you do it without relying on a company’s own narrative or marketing?

Doing our demo this way has given them a way to answer that question on their own terms, not just ours.

Taking the leap

Launching an open demo meant giving up control over how Mercury was first experienced. Letting any and everyone see everything we were building. Showing features in their earliest, sometimes roughest forms.

But betting on transparency meant betting on our customers. Founders and business owners make complex decisions every day — we trusted they could evaluate our product and decide for themselves whether it fit their needs.

That trust reinforced what mattered: not our own assumptions about what businesses needed, but making room for all kinds of builders to find their own path forward.

Try it yourself

If you haven’t used Mercury before, check our demo to see what we're building. And if you have thoughts—whether you're a founder evaluating tools, someone curious about product design, or just interested in how we’re approaching this— I’d love to hear them.

Reach out at [email protected] or come chat to us on X: https://x.com/jdsimcoe (or https://x.com/mercury)

About the author

Jonathan Simcoe is a software designer and writer based in Portland, Oregon. He has published a children’s book about curiosity and written previously for Dwell.com. His work sits at the intersection of technology, design, parenting, and faith.

Share article

Disclaimers and footnotes

Mercury is a fintech company, not an FDIC-insured bank. Banking services provided through Choice Financial Group and Column N.A., Members FDIC. Deposit insurance covers the failure of an insured bank.