Business Economics and Psychology at UCLA. I founded BetRoyale, a real-money skill-wagering platform, and took it 0 → 1 alone: strategy, spec, design, experiments, fraud rules, and growth.
Los Angeles, CA
Two Clash Royale players each post a wager. They get matched, add each other in game, and play a friendly 1v1. Supercell's official API reads the battle log and settles the match automatically. Winner credited, loser debited, money through PayPal. No screenshots, no disputes, no trusting a stranger.
Founder and sole operator. I wrote the vision and the spec, designed every screen and the design system, researched the legal constraints, designed the fraud rules, ran acquisition, and built the QA harness. I directed engineering with AI as the implementation layer and made every tradeoff call myself.
Build: concept to live product, solo, while carrying a full course load.
Live: May to June 2026.
Wind-down: I shut it down after identifying a dependency risk tied to a third-party API partner's terms of service. That was a judgment call, not a failure to keep it running.
Clash Royale has a huge competitive player base and no sanctioned way to play for money. The blockers weren't technical. They were trust (who confirms who won), liquidity (an empty queue kills the product), and law (skill wagering is legal in some states and not others).
In gambling, chance decides the outcome. Here it's decided by how well you play a game with a ranked ladder and a pro scene. You aren't betting on someone else's match, you're staking your own performance. Legally and psychologically those are different products.
That call set the legal exposure, the addressable market, the brand, and the wording of every button. It also banned casino visuals and any outcome-promise language from the marketing.
I sorted all 50 states into permitted, prohibited, and ambiguous, then treated ambiguous as prohibited. That cost me 15 states including New York, Texas, Illinois, and Pennsylvania, four of the biggest player pools in the country.
Building isn't the interesting part. Choosing what not to build, and knowing what it would cost if you chose wrong, is.
The clearest analytical problem I had, and the one where the incentives were least obvious. This is the experiment design I wrote, unedited in substance.
Watching the match and wager tables in SQL, a pattern showed up: a chunk of depositors were staking a large share of their balance on their first real-money match, winning or losing once, and leaving. Deposit, one big match, cash out or churn.
That's terrible for a business whose revenue is a take rate on match volume. A player who makes twenty $1 wagers is worth far more than one who makes a single $20 wager, and they usually have a better time.
Anchoring the default wager chips to a share of the player's actual balance, adding a confirm step above 25% of balance, and framing stakes as "% of balance / rounds left" would cut the median wager-to-balance ratio by about 25%, concentrated in new and casual players, with no drop in deposits or revenue.
I pre-registered the direction and the kill signal before running it, so I couldn't rationalize a bad result afterward.
| Assignment | User-level, deterministic 50/50 hash on user ID. Not per match, so no one sees both versions. |
| Cohort | New signups only. Bet-sizing habits form on first exposure, and changing the UI under existing users adds noise plus a support spike. |
| Treatment | Three nudges shipped together: balance-scaled default chip, confirm step above 25% of balance, percent-of-balance framing. |
| Population | Real-money matches only. Free-coin matches are a guardrail, not a primary metric. |
| Stopping | Fixed N up front, roughly 300 depositors per arm with at least one balance wager. No peeking and stopping. |
Primary. Median wager-to-balance ratio per arm. Median rather than mean, because the ratio distribution is right-skewed by a handful of large players.
Secondary. Matches per dollar deposited. Mean real-money matches per depositor. Share of depositors who withdraw after two or fewer matches, the hit-and-run rate.
Guardrails. Deposit conversion must not fall. Revenue per user must not fall. Self-exclusion and deposit-limit hits must not rise.
Significance. Mann-Whitney U on the primary, because the ratio isn't normally distributed. Two-proportion z-test on conversion. Threshold p < 0.05, with guardrails weighted conservatively: a revenue dip that isn't significant is still a yellow flag.
-- PRIMARY: median wager-to-balance ratio on real-money matches, by arm SELECT e.metadata->>'arm' AS arm, count(*) AS wagers, count(DISTINCT e.user_id) AS users, round(percentile_cont(0.5) WITHIN GROUP ( ORDER BY (e.metadata->>'ratio')::numeric)::numeric, 4) AS median_ratio, round(avg((e.metadata->>'wagerCents')::numeric)/100.0, 2) AS mean_wager_usd FROM user_events e WHERE e.name = 'wager_placed' AND e.metadata->>'currency' = 'balance' GROUP BY 1 ORDER BY 1;
The schema didn't store the player's balance at the moment of the bet, which is exactly what the primary metric needs. Reconstructing it afterward from settlement records would have been guesswork.
So before launching I added one event, wager_placed, emitted when a wager locks and before settlement, carrying the arm, the stake, the balance at that instant, and the precomputed ratio. No schema migration needed, because the events table already stored JSON metadata.
Before building the onboarding and match loop, I mapped the entire journey in FigJam: every screen, every branch, every place a player can fail a check and what happens to them when they do. It's a big board, so it's embedded live. Pan and zoom it here, no Figma account needed.
A real-money product has more failure states than happy paths. A player can be in an ineligible state, unverified, missing a player tag, missing a friend link, short on balance, mid-match, or blocked from cashing out. Each one needs a defined destination. Drawing it was the only way to find the dead ends before users did.
The decision diamonds are the compliance and readiness gates: age and state eligibility, email verification, identity verification for deposits, tax info for cashouts. The flow makes it visible that every gate sits on the money path and none of them stand between a new player and their first match.
Mapping it surfaced the contextual next-step card. Once you can see every state a player can be stuck in, the obvious fix is a single component that always names the one action that unblocks them, instead of a profile page full of incomplete fields.
The document the product was built from. Below is the part that shows the thinking: what I decided not to do, and what would have told me I was wrong.
| Metric | Why it matters | Target |
|---|---|---|
| Signup to first match | Tests whether free coins actually remove the trust barrier | Under 3 min, 60%+ play once |
| Deposit conversion | Whether free play converts into real stakes | 20% of signups |
| Weekly wagers per depositing user | The revenue driver, since the fee is per settled pool | Grows week over week |
| Settlement dispute rate | Validates the whole API-settlement premise | Near zero |
| Risk | Severity | Mitigation |
|---|---|---|
| Platform dependency | Critical | Settlement runs entirely on a third-party API governed by terms the platform doesn't control. Get the platform relationship settled before scaling spend, not after. This risk was underweighted in practice. |
| Cold start | High | A wagering marketplace with nobody in it has zero value to the first user. Peer-to-peer challenge board over automated matchmaking, free starter coins, community partnerships for concentrated early liquidity. |
| Tilt and problem play | Medium | Unresolved as of v1. Any retention mechanic aimed at losing players must clear a responsible-gaming bar first, and none proposed so far does. Deliberately left open rather than shipped badly. |
I'm a junior at UCLA, double majoring in Business Economics and Psychology, graduating in 2028. The combination isn't an accident. Economics gives me the incentive model and the analytical toolkit. Psychology tells me why people don't behave the way the incentive model says they should. Product sits exactly in that gap.
Alongside BetRoyale I've worked on financial reporting and KPI dashboards at Lambda Chi Alpha Headquarters, financial management consulting through UCLA's AY Consulting, and I'm joining a UCLA research team on Designing Better AI Tutors.
I'm looking for a Summer 2027 internship in product management, product strategy, analytics, or growth. I'm most useful somewhere I can own a problem end to end rather than a slice of one.
Analysis
SQL, R, econometrics, A/B testing and experiment design, Google Analytics 4, Excel
Product
PRDs and specs, Jira, roadmapping, QA design, competitive and legal research
Design
Figma and FigJam, design systems, mobile-first interface design, PWA patterns
Technical
REST API integration, relational and vector databases, RAG pipelines, PostgreSQL