Gleam Revenue

Founders running on Stripe can see every charge but not the number that matters: where MRR actually moved this month and who churned. I built Gleam Revenue to answer that on a phone. A founder connects their Stripe account through OAuth and gets live MRR, ARR, a churn feed, a plan-level breakdown, and a daily email digest. The whole thing is read-only by design.

That read-only promise is the spine of the build. Stripe only grants standard Connect platforms the read_write OAuth scope, so I enforced the constraint in code instead: a Vitest test walks the source tree and flags any stripe.*() call that isn't a list, retrieve, search, or an auth call, and it runs in CI on every push. MRR is calculated from Stripe Price objects rather than invoice amounts, then broken into new, expansion, contraction, churn, and reactivation movements so the chart explains itself.

The sync layer is built to survive Stripe's timing rules. Webhooks write the raw event to Postgres first and process it asynchronously through Inngest, which keeps the endpoint inside the 5-second ack window; idempotency is enforced twice, on Stripe's event.id and again on Inngest retries. Around a dozen Inngest jobs handle initial sync, nightly delta, weekly reconcile, MRR snapshots, the email digest, and disconnect handling. Row-level security landed in the first migration, not bolted on later, and Connect tokens are stored under AES-256-GCM with a unique IV each.

I shipped it across five weekly milestones on the locked stack: Next.js 14 on the App Router, Supabase Postgres with Drizzle, NextAuth v5, Inngest, Resend, and Sentry, deployed on Vercel. The headline result is a guarantee: a financial tool wired to live customer Stripe accounts that provably cannot write to them, checked by the test suite on every commit.