This case study is private and an on-going project. Please do not share beyond the intended audience - hi team Gumloop!
Chance.live - Trading Card Game Startup
Designing a marketplace, a livestream platform, and a creator dashboard at the same time
Helping define Chance's creator ecosystem from the ground up: turning a broad business vision into connected buyer, creator, and operational experiences while navigating technical constraints, product tradeoffs, and startup-speed execution.
Company
Chance.live
ROLE
Systems Designer
Product Growth Strategist
Team
Front-end Developer
12 Person Company
Duration
1 week
July 2026

Context
Chance.live is building a more social future for trading card collecting
Chance.live is a Series A startup reimagining how people buy, open, collect, and trade Pokémon cards online.
The trading card industry has traditionally been fragmented. Collectors buy packs from online stores, watch livestreams on separate platforms, participate in Discord communities, track collections in other tools, and coordinate purchases through DMs, spreadsheets, and payment apps.
Chance's vision is to bring those experiences together into a single ecosystem. Instead of collecting alone, users can discover creators, participate in live pack openings, build collections, and engage with a community centered around the hobby they already love.
A major part of that vision is creators. Today, Chance works with dozens of trading card creators and livestreamers who help introduce new collectors to the platform. These creators are our community. They entertain, educate, build trust with collectors, and create the social experiences that make the hobby fun.
As Chance continued to grow, the team saw an opportunity to build infrastructure specifically for creators and their audiences.
The goal was to create a connected ecosystem where collectors could discover creators, purchase products directly through livestreams, track their orders, receive their pulls, and continue engaging with the community long after the stream ended.
To get there, we needed to rethink how creators, buyers, and the platform itself interacted.
The Problem
A creator ecosystem existed, but the infrastructure didn't
Chance had built strong relationships with creators, but the workflow powering creator sales was held together by spreadsheets, manual processes, and a lot of coordination from a very small team. For creators, selling Chance packs during livestreams meant stitching together their own workflow. A creator would promote packs on stream, collect payments through external tools, keep track of purchases in spreadsheets, manually determine who bought what, and then coordinate fulfillment after the stream ended. As the number of orders increased, so did the operational burden. The process worked, but it wasn't scalable.
For buyers, the experience wasn't much better. Users were often redirected to a basic e-commerce storefront to purchase packs, disconnected from the livestream experience that motivated them to buy in the first place. After completing a purchase, buyers had little visibility into what happened next. Questions like: "Did my order go through?" Where am I in line? Has my pack been opened yet? What cards did I pull? often required manual communication and troubleshooting. The experience felt fragmented despite being centered around a highly social activity.
Internally, we faced another challenge. Creators were one of our primary growth channels, but there was very little visibility into creator performance. Many creators didn't know where to find their referral links, how many users they were bringing to the platform, or how their audiences were converting.
As a result, the team spent a significant amount of time manually answering questions, tracking referrals, and helping creators understand their impact. What should have been a scalable growth engine required constant hands-on support. The underlying problem wasn't a missing page or missing feature. The problem was that the creator ecosystem had never been designed as a system. Buyers, creators, and the internal team were all solving the same problems manually.
the opportunity
Designing a creator economy, not a creator page
The initial request sounded straightforward: "Let's build creator profiles where users can buy packs." But once I started mapping the experience, it became clear that the real challenge wasn't the UI. It was the system underneath it. A buyer might discover a creator, watch a stream, purchase packs, track their position in line, watch their packs get opened live, and receive cards in their collection. Meanwhile, creators needed a completely different set of tools to manage orders, open packs, fulfill pulls, and keep their stream running smoothly. Every decision affected multiple people, multiple screens, and multiple business goals.
Before designing anything, I started asking:
How does a creator manage orders without exposing private information on stream?
What happens when a creator wants to buy from another creator?
What happens on mobile?
Which features actually matter for V1?
What should we build now versus later?
The more questions I asked, the more the project shifted from UI design into product design.
My Role
🎩🧢👒🎩🧢👒🎩🧢👒🎩🧢👒
On any given day I'm:
Mapping user flows
Prioritizing features
Defining product requirements
Auditing edge cases
Writing implementation specs
Designing interfaces
Building prototypes
Vibe-coding working experiences
Collaborating with founders and engineers
Making tradeoff decisions between ideal UX and implementation reality
One thing I've learned quickly is that startups don't need designers who only design screens. They need people who can reduce ambiguity. A large part of my job has been figuring out what we're actually building before we build it.
process
Finding flaws before they destroyed our credibility or got us sued
As I mapped the ecosystem, I began identifying areas where the original approach would create friction for users, creators, and engineering. For example:
The same pages were expected to serve both buyers and creators despite them having completely different goals.
Creator management tools risked appearing on livestreams.
Certain mobile experiences worked in theory but broke under real browser constraints.
The way our URLs were set up assumed creators would only ever act as creators, when in reality they might also want to participate as buyers.
Certain data about other creators could not be legally displayed on a dashboard.
Rather than designing around these issues later, I surfaced them early and proposed alternative approaches. This became less about polishing interfaces and more about shaping the product architecture itself.
Systems Thinking
Building five products that work as one
The creator ecosystem evolved into five connected experiences, each serving a different purpose.
Creator Discovery
Help users discover creators, browse live streams, and decide who to watch.
Creator Storefront
Turn viewers into customers through live shopping, pack purchases, and order tracking.
Creator Queue
The operational side that allows creators to manage purchases, process orders, and fulfill pulls without disrupting their stream.
Creator Dashboard
Give creators visibility into referrals, payouts, campaigns, and business performance.
Community Dashboard
Help creators understand and celebrate their community through collection insights, milestones, and audience engagement.
Vibe-Coding as a Design Tool
The fastest wireframe is a working product
One of the biggest changes in my process recently has been using AI coding tools as part of design exploration.
Instead of stopping at wireframes, I've been building working versions of ideas. Not production-ready code. Fast, interactive prototypes that let me test flows, validate assumptions, and communicate concepts much more effectively than static screens.
Sometimes it's easier to build something than explain it.
Instead of:
Idea → Wireframe → Mockup → Prototype → Test
The feedback loop becomes:
Idea → Prototype → Test → Iterate
For startup environments where speed matters, this has been incredibly valuable. Vibe-coding has become a core part of how I think through product problems.
Prioritization
Shipping the smallest version that creates value
One of the hardest parts of this project hasn't been generating ideas. It's been deciding what not to build.
There are endless features we could add:
Creator analytics
Social systems
Loyalty mechanics
Better queue management
Collection sharing
Stream interactions
Advanced notifications
The challenge is determining what creates the most value today. Every feature competes against engineering resources, timelines, and business priorities. I've spent a lot of time working with founders to identify which features unlock the most learning and move us toward product-market fit the fastest.
Impact
Creating the foundation for creator-led growth
This project is still actively being built, but the work has already influenced how the company thinks about creators.
So far I've helped:
Define the creator ecosystem strategy
Shape the information architecture
Identify critical edge cases before implementation
Establish the first creator-facing workflows
Create foundations for future creator tooling
Accelerate product exploration through AI-assisted prototyping
Align product decisions with technical realities
Most importantly, I've helped turn a broad business idea into a tangible product roadmap.
Work in Progress
We're actively building, testing, learning, and evolving the system. As a result, this case study focuses less on final screens and more on the thinking, product decisions, and systems work happening behind the scenes. I'll update this with outcomes, metrics, and learnings once the ecosystem launches and real users begin using it. For now, this is a snapshot of what it looks like to be a founding designer at a startup: navigating ambiguity, making product decisions, building systems, and helping transform an idea into something real.


