⚡︎ Thunder Compute ⊹ GPU Cloud to accelerate AI workloads

How do you get strangers to trust each other to share expensive compute hardware? Backed by YC.

 

Role: Product designer

Team: 2 Founders

Stage: Pre-funding

Outcome: Initial MVP designed → 700k seed funding from YC

 

I turned an early GPU marketplace concept into a product that strangers could trust. As Thunder's first designer, I shaped the marketplace, its trust architecture, and the MVP that helped secure investment from Y Combinator and angel investors.

 
 

Design during the founder stage was more systems-design forward than I’d expected.

At the founder stage, design didn’t actually involve much visual creation. My role was focused on figuring out exactly what it takes for a stranger to hand over money or hardware, then designing the system that makes that complex interaction real.

So, why does compute scarcity deserve to be solved?

Students, indie developers, and small startups are paying the price for AI compute scarcity. GPUs currently require large upfront commitments to cloud providers such as AWS and Azure, even though the hardware largely sits idle while they’re reserved.

Meanwhile, capable GPUs sat idle in homes and labs.

Thunder's idea was to connect the two. That opens a market, but crowd-sourced resources come with multitudes of trust-related issues.

I focused on simplifying a complex concept for consumers, and baking-in trust.

A trust model for a peer-to-peer market

I replaced direct renter and host contact with a black box (network-mediated system) that held both sides accountable and reduced the potential for fraud incidents.

A payments barrier caught early

My research exposed crypto wallet setup as a primary adoption barrier → moved to traditional payments before building t.

Foundational servicing models

The baseline service flows supported the seed raise and largely survived the handoff to an external design team.

Striking a balance between anonymity and trust.

When I joined, Thunder was a concept and a crypto payment model borrowed from Helium, a company which rewards people with tokens for contributing hardware.

Hosts would earn tokens for lending compute, and renters would pay through a blockchain-backed mechanism. My first job was figuring out what problem we were actually solving, and for whom.

 

Instead of comparing features, I compared how each platform makes strangers willing to transact. AWS sets the bar for reliability but buries it in enterprise setup. Vast proves crowdsourced supply works but exposes strangers to each other directly. Helium and Render make contributions verifiable, but crypto onboarding scares off renters. That pointed Thunder to a clear position: peer-to-peer prices, with the network as the trusted middle.

 

Competitive research pointed Thunder to a clear position: peer-to-peer prices, with the network as the trusted middle.

We put GPU sharing in a black box.

Anonymity felt like a risk: anonymous users can commit fraud and vanish. But direct contact between strangers was the bigger one.

So I made renters and hosts anonymous to each other and fully accountable to the network. Credits are verified before a job runs, hosts are paid once completion is recorded, and neither side ever sees the other.

I took extreme measures to simplify users’ roles in the Thunder Network.

We took Thunder from concepts of an involved marketplace app → A simple terminal + web dashboard concept.

 

1. Thunder provides GPU compute → users.

Green arrows indicate renter’s actions. We distilled the user’s responsibilities down to two actions:

  • purchase Thunder credits

  • run programs using Thunder credits

 

2. Hosts share GPU compute → Thunder’s network.

Teal indicates the host’s actions. We distilled the host roles as well to two actions:

  • connect their GPU to the Thunder network

  • get paid

Funneling users through crypto would be creating a high friction barrier.

The original model asked renters to set up a crypto wallet before running anything. Mapping the renter flow end to end made the cost visible: the setup steps outweighed Thunder's price advantage, and users said they'd pay more elsewhere for a payment they already understood.

I raised this with the founders early, and the team moved away from crypto as the sole payment method before building it.

Reflections

The MVP I helped establish helped the founders raise $700k and go full time on Thunder. As the company matured, Thunder has since shifted away from crowd-sourced compute due to it’s network unreliability, but the baseline flows I designed have mostly stayed intact.

At the founder stage, design isn't wireframes first. It's deciding what has to be true for a stranger to hand over money or hardware, then building the system that makes it true. That question runs through all my work, from fraud prevention at Truist to here.