Menu
Back to Case Studies

SaaS Billing ·Confidential, B2B SaaS platform

Finance sees MRR, usage and per-account activity in one place, and changes the subscription there.

A SaaS company running Free, Pro and Enterprise plans plus usage-based billing across many organizations, where Stripe alone gave no clear view of MRR.

Where this fits

Best for finance teams at SaaS companies tracking MRR, usage and subscriptions across many accounts, without pulling product engineers off the core app.

Stripe billing and product usage in one live view. One developer, two months.

  • Stripe + PostgreSQL
  • MRR, churn, per-org usage
  • Subscription actions built in

What we did

  • Joined Stripe billing with product usage data from PostgreSQL
  • Built MRR, usage revenue and per-organization breakdowns
  • Added cohort retention so churn is visible month by month
  • Moved plan upgrades, trials and cancellations into the dashboard

Result

The GTM team reads MRR, churn and per-account usage from one live view instead of asking engineering for a query. Upgrades, enterprise assignments, trials and cancellations happen in the same place.

Billing analytics: MRR against usage revenue, revenue split by plan, top organizations by MRR, and month by month cohort retention. Demo data.

The hard part

MRR is not a field in Stripe, it is a definition someone has to defend. Stripe thinks in customers, subscriptions and proration events while the product thinks in organizations, users and requests, so joining them means choosing one identity key and one moment revenue counts. Get that wrong and a mid-cycle upgrade quietly counts twice.

Stack
StripePostgreSQLRetool
Focus
SaaS BillingStripeMRRFinance AnalyticsFintech

Facing a similar problem?

Tell us where it stalls today, and we'll tell you how we would approach it.