⚡︎ Thunder Compute ⊹ GPU Cloud to enable AI workloads
Designed a platform for developers to host and borrow GPUs. Backed by YC.
Role: Product Designer
Team: 2 Founders
Stage: Pre-funding
Outcome: Initial MVP designed → founders secured 700k seed funding from YC + angel investors to build Thunder full-time
Timeline: 6 Months
I helped turn an early GPU-sharing concept into a coherent product model, designing the marketplace, trust architecture, and initial MVP before funding.
I designed the initial MVP for Thunder Compute leading up to their initial investment from Y Combinator, among other angel investors.
⚡︎ thunder explain --impacts
The following wireframes I designed illustrate Thunder’s initial concepts, while it was still a crypto-based GPU share service.
⚡︎ thunder deliver --prototypes
⚡︎ thunder load --logos
> I designed Thunder’s service models.
Thunder’s service connects GPU users with hosts through a credit-based system. Users purchase credits in the Thunder Console, which are logged in Firebase for speed and finalized on the Blockchain for trust. Compute jobs are submitted through the Thunder Network, executed by hosts, and returned to users. Hosts are paid out in credits after their jobs complete, ensuring both affordability for users and reliability for providers.
Hosts register, connect, or disconnect GPUs through the Thunder Host App, which communicates their capacity to the Thunder Compute Network. Jobs are assigned, run on the GPU, and returned through the Host App. Job completions are recorded via Firebase and finalized on-chain, with credits exported to the Thunder Console. Hosts receive payouts in their Thunder Wallet and can redeem them at any time. This flow gives hosts full control over participation while ensuring trusted, verifiable rewards.
When a user starts a program from their CLI, the request is passed through their application into Thunder’s Network. The network checks if the user has sufficient credits. If additional funds are needed, the user can top up their crypto wallet, which updates back into the system. Once funds are confirmed, the job is assigned to an available host GPU, executed, and the results are returned through the network, back to the user’s program, and finally displayed in the CLI. This ensures jobs only run against verified balances while giving users a seamless experience of submitting compute tasks and receiving results.
> Developers are paying for the cost of scarcity.
Currently, individual developers, small teams, and startups, are being forced to pay hundreds of thousands of dollars up front for GPU capacity they may only partially use. It’s an unsustainable cost barrier.
We gathered informal feedback from students and researchers about GPU accessibility, payment expectations, and trust barriers.
> Grad students and PhD researchers in ML/AI loved the idea of “renting a GPU quickly”, but didn’t want surprises in billing or availability.
> Independent developers and early-stage founders were price-sensitive and hateful of a heavy onboarding experience.
> Small startups wanted to explore the computing space but unable to afford AWS-scale pricing.
> What if, we could arrange a crowd-sourced GPU hosting/borrowing service?
This approach allows users to partake in the reservation model that cloud providers require, but dramatically lowers the effective cost of short bursts of compute. Users can pay only a fraction of today’s prices while still getting the performance they need, and GPU owners with idle machines could earn income by renting out their hardware online.
Thunder looked to Helium’s decentralized wireless network as inspiration for its payment model. Helium enables individuals to contribute their 5G hotspots and be rewarded in a transparent, tokenized way.
Thunder wanted to mirror this system: GPU hosts could be rewarded for contributing compute, while borrowers could pay using a simplified, blockchain-backed mechanism that ensured trust and minimized fraud.
> I took a look at similar competitor offerings.
Through initial analysis, we began to map our initial market positioning. Like Vast, we wanted to achieve a decentralized hybrid structure. We leveraged crowdsourced GPUs while managing them through a service layer. Vast’s peer-to-peer approach also inspired Thunder, but we aimed to layer in stronger safeguards to build customer feedback centered platform. We initially wanted to position to use crypto, seeing the success of competitors such as Render. At the time, blockchain-based contracts were seen as a way to create transparent, automated payments between strangers. Lastly, we wanted Thunder to feel quick and familiar, and not bogged down by AWS’s enterprise setup or Render’s crypto hurdles.
⚡︎ thunder build --trust
I found that unlike a centralized cloud service, a peer-led marketplace lacks a built-in layer of trust. A peer-to-peer model raises key risks. Renters might pay but never receive access, hosts might provide resources without being compensated, and bad actors could misuse another person’s GPU.
-
A renter might pay but never actually receive working GPU access. Or, a host might provide GPU time but never get paid.
-
Users can be anonymous, making it easier to disappear after fraud or misuse. And without oversight, bad actors could run malicious workloads (e.g., crypto mining, spam, hacking) on someone else’s hardware.
To embed trust into the system, I removed direct host–user interaction and designed a network-mediated model. This design created a subconscious layer of accountability. The network itself became a centralized source of truth, while preserving the flexibility and affordability of peer-to-peer GPU sharing.
> Crypto payments made users reluctant to try Thunder
Helium’s crypto model shows how individuals can passively contribute networks in exchange for crypto. Thunder envisioned something similar, with hosts donating GPU compute and earning tokens. But for those renting GPU’s, consistency and ease of use often outweighed the cost. Many chose more expensive providers simply because they offered straightforward payments and reliable compute access. This highlighted a key adoption barrier:
Requiring users to set up a crypto wallet created friction that overshadowed Thunder’s extremely competitive pricing.
My early user flows surfaced this risk early, and the team was able to pivot away from crypto as the sole payment method early on.
⚡︎ thunder write --reflections
Thunder taught me that early-stage startup design isn’t just about making wireframes or diagrams. It’s also about shaping trust, strategy, and credibility at the very beginning of a company’s story.
Thunder was just an idea when I joined, so my work became the team’s first coherent framework. Through my service design and research, I helped the founders refine their vision and set them up for success.
Looking ahead, I also explored future product avenues with the founders to strengthen investor pitches and open doors for growth:
Optimizing data centers for higher GPU efficiency.
Serving corporate clients with more predictable, scalable and cheaper compute than typical cloud providers.
Helping individual hosts optimize their own GPU performance.
Supporting private rentals to specific users or teams to optimize their own resources.
Expanding to other niches such as rendering workloads, to attract customers such as Render Network’s.
Although Thunder’s services have shifted as they focus on building their core infrastructure and respond to customer feedback, the baseline flows I designed have mostly remained intact. As the company matured, my work was handed off to an external design team.
Through this work, I learned that the real value of design at the founder stage lies in instilling confidence in both users and investors.