Building Subscriptions from Zero, Across Six Markets

A multi-phase 0→1 monetization system spanning content gating, flexible creator pricing, payment recovery, and moderation — built for a live-streaming and esports platform.

Role: Product Manager Company: Loco Duration: Sep 2024 – May 2026 Tools: Stripe, Retool, Amplitude

The problem

Loco had no subscription monetization layer. Creators had no recurring revenue mechanism tied to the platform, and there was no infrastructure for recurring payments, tiered access, or the moderation and compliance work that comes with handling money across markets. This needed to be built from zero — not a redesign of an existing system.

Approach

I owned the system end-to-end across 6+ months of development, shipping a multi-phase MVP: content gating across streams, VODs, and chat; badges and stickers; free preview; and moderator access controls — integrated with Stripe for recurring payments. Rather than fixing creator pricing centrally, I introduced a web-based flexible pricing tool built on Retool, letting streamers set and adjust their own subscription price within tier-specific bounds defined by the supply team.

The hard decisions

Regulation isn't uniform. I researched consumer protection law across Turkey, Germany, South Korea, India, Brazil, and other target markets, and found consent requirements for price changes varied meaningfully by jurisdiction. Rather than build one flow and patch exceptions later, I split the architecture upfront into explicit-consent and deemed-consent paths, with a 30-day grace period enforced via Stripe Scheduler.

Payments fail — plan for it. I built a recovery system distinguishing soft declines (insufficient funds, network issues) from hard declines (invalid or stolen cards), each routed through Stripe webhooks into automated retry logic and localized communication — 9 email templates translated across 13 languages — to reduce involuntary churn rather than losing subscribers to a failed card silently.

Moderation and monetization interact. Streamers needed to grant moderation access to subscriber-only streams without handing out paid perks like stickers or badges — so I designed granular, per-moderator access controls, benchmarked against Twitch, Kick, and YouTube Live. On the safety side, I added subscription-aware moderation modals that surface a subscriber's badge during mute/timeout actions, so moderators can make an informed call before muting a paying subscriber.

Pricing: a reframe, not just a model

The question as handed to me was narrow: when a creator's price rises, do existing subscribers migrate to the new price, or keep the old one? The team had been debating the migration mechanic for weeks. Working through it, I found that question was close to a non-decision — at Loco's 95/5 creator revenue split, the platform holds roughly 5% of the upside but absorbs effectively all of the churn, support, and regulatory cost. I named that tension explicitly and optimized for creator earnings, since that reflected the actual business intent, rather than defaulting to whichever mechanic felt safest.

With no historical subscription data on a pre-scale product, I separated assumption-free arithmetic from modeled estimates. Raise price by a factor r, and revenue is flat at exactly a 1 − 1/r subscriber loss — that holds regardless of any churn assumptionHard. From there, I modeled the actual churn by decomposing it into three named mechanisms — notification-driven attrition, price sensitivity, and consent-flow abandonment — each mapped to a distinct product lever, and ran the conclusion across low/mid/high parameter bands so it held even under adverse assumptions.

What I got wrong, the first time. I'd anchored the churn benchmark on platform-level subscription churn (Netflix-style), when Loco's product is a per-creator channel subscription — a structurally different comparable with meaningfully higher churn. My first model also had grandfathering (keeping existing subscribers at their old price) winning long-term, but only because I'd assumed new-subscriber growth would offset the forgone revenue — when the price increase itself is what suppresses that growth. Correcting both, grandfathering lost at every horizon, and two of my original five "pricing strategies" turned out not to be real options at all — they were artifacts of other platforms' technical constraints, and including them had flattered my own recommendation by comparison.

The corrected model found that small price steps lose money: below roughly 8% in standard markets, and roughly 46% in consent-required markets, the notification cost alone exceeds the gainProjected. Consent-required markets need roughly 5× the price step to reach the same breakeven. And consent-completion rate turned out to be a pricing lever in its own right — moving it from ~55% to ~85% was worth roughly as much as doubling the price step, at no cost to the subscriber. This is pre-launch modeling with no realized revenue outcome yetSelf-reported — what changed is where engineering effort went: from migration-mechanic logic to step calibration and consent-flow conversion.

What shipped

Planned but not shipped

Cancel auto-renew & reactivation

Designed a cancel-and-reactivate flow using Stripe's cancel_at_period_end API, preserving original renewal dates on reactivation, with edge cases defined for mid-block cancellations, post-expiry resubscriptions, and streak preservation for future gamification. PRD complete; not prioritized against other roadmap items at the time.

Moderation-based subscription pausing

Designed a moderation-triggered pausing system: auto-pause active Stripe subscriptions on a streamer block to prevent subscriber charges during a violation, auto-resume with retroactive invoice collection on unblock, and auto-cancel after 30+ day blocks, with strike-based escalation. PRD complete; didn't clear the prioritization bar against other Trust & Safety work.

Android subscription flow

Designed a cross-platform Android flow routing users through email-to-mWeb-to-Stripe checkout to bypass Play Store billing fees, with OTP authentication, deep-link return to app, and handling for interrupted multi-session flows. PRD complete; Android represented a smaller share of subscription revenue than iOS/web at the time, so it didn't get engineering allocation.

← Timeline Missions Quest Engine →