// Case Study · Retention for a platform nobody else can reach
ChurnGuard
Retention Tooling · Whop Creators · Solo Build
Whop’s native analytics tell a creator they lost members. ChurnGuard tells them who is about to leave, and acts on it. The retention category off-platform (Churnkey, Churn Buster, Paddle Retain) plugs into Stripe, Shopify, Recurly, or Chargebee. Whop owns payments on its own platform, so none of those tools can reach a Whop creator at all. That gap is the entire reason the product exists.
34 seconds through the running product: scored members, alerts, a member profile, and a two-click win-back send.
// 01 · Live in production
The app is live and running. It was submitted to the Whop App Store on 2026-07-29 and is awaiting review.
Everything in the screenshots below comes from a seeded demo company with twenty members. The interface is real and the numbers in it are not, so no figure visible in these frames should be read as a result.
// 02 · Scoring and alerts
Each active member carries a 0 to 100 composite built from four weighted signals: payment history at 35%, engagement at 30%, tenure at 20%, and plan value at 15%. Tiers are healthy at 70 and above, at-risk from 40 to 69, critical below 40. Every profile shows the factor breakdown and a 7 and 30 day trend rather than just the number.
When there is no activity data, it reports "not enough data" instead of producing a confident score. A retention tool that invents a number for a member it knows nothing about is worse than one that admits the gap, because the creator acts on it either way.
// 03 · How it works
There is no login page and no OAuth flow. The app runs in an iframe inside the Whop dashboard, and Whop injects a signed user token on every in-iframe request. The layout verifies that token, gates on a live admin access check against the company in the URL, then auto-provisions the company and user rows on first visit. Skipping an auth surface entirely removes the largest thing there is to get wrong, and it only works because the platform is the one asserting identity.
Webhooks are idempotent by construction. The handler verifies the signature, writes an event row with a null processed-at, runs the handler, and stamps processed-at only once the handler completes. A crash halfway through is reprocessed cleanly on redelivery rather than silently swallowed. Getting this wrong on a billing webhook means either double-charging someone or losing a cancellation, and both are the kind of bug you find out about from a customer.
Eight cron jobs run daily, each behind a bearer token: member sync, score calculation, trial reminders, trial checks, drip processing, content generation, the daily digest, and retention purging. That last one enforces the data lifecycle: after a subscription expires, access is read-only for a week, locked behind an upgrade screen for the rest of ninety days, and the data is deleted after that.
Three win-back playbooks run automatically. Onboarding Rescue for new members who go quiet, Silent Quitter for healthy members starting to slide, and Payment Saver for failed payments. Each reports its save rate and retained revenue, defined as members still subscribed thirty days after outreach. A creator can also send from their own connected inbox or as a Discord DM in two clicks.
The stack is Next.js on the App Router with TypeScript, Supabase Postgres with row-level security, Upstash Redis for rate limiting, Resend for creator alerts alongside creator-connected mail for member outreach, and Discord DM delivery with email fallback. API keys are encrypted at rest. Billing is Whop-native in-app purchase, so there is no Stripe integration to maintain.
Built and run solo
Screenshots are from a seeded demo company. ChurnGuard has no customers yet, so there is no traction to report and nothing on this page should be read as one. Submitted to the Whop App Store on 2026-07-29, awaiting review.