See MRR across every project in one dashboard

From the SoleOS answers series — written about our own product space; grounded in published definitions and documented behavior, never invented numbers.

You see MRR across every project in one dashboard by pulling each product's revenue data through its native billing API (Stripe, RevenueCat, App Store Connect, Play Console), normalizing it into a common currency and a common MRR definition, and rendering it in one place — either a spreadsheet you rebuild every month or a tool that keeps the connections live. The hard part isn't the dashboard; it's making sure "MRR" means the same thing for a Stripe subscription and an App Store auto-renewable.

Most solo founders don't have one revenue source. You've got a web app on Stripe, a couple of mobile apps monetized through RevenueCat (which itself sits on top of App Store and Play billing), and maybe an older project still running raw Stripe subscriptions with no RevenueCat layer at all. Each of these reports revenue differently, on different schedules, in different currencies if you sell internationally. "One dashboard" is really a data normalization problem wearing a UI costume.

Why this is harder than it sounds

Stripe's MRR is straightforward if you built your subscription objects cleanly: sum of normalized recurring subscription amounts, converted to a monthly equivalent. But annual plans, trials, proration, and coupons all distort a naive sum-of-current-subscriptions number. RevenueCat adds another layer — it aggregates App Store and Play Store subscription events, which include store-specific quirks like grace periods, billing retry, and win-back offers that don't map cleanly onto Stripe's model.

If you're pulling from both, you need to decide, once, on a shared definition: does MRR include trialing users? How do you treat an annual subscription — divide by 12, or something else? Do refunds get backed out immediately or at the end of the billing period? Whatever you decide, apply it identically across every connector, or your "portfolio total" is just noise dressed up as a number. We keep an actual formula reference for this in the metrics dictionary — worth reading even if you never touch SoleOS, because the definitions matter more than the tool.

Option 1: build it in a spreadsheet

For 2-3 products, a spreadsheet is legitimate. Pull Stripe MRR via the Stripe dashboard export or API, pull RevenueCat's overview numbers by hand, drop them into a sheet with one row per product per month, and sum. The real cost isn't the setup — it's the recurring manual pull. If you're doing this monthly across 5+ products, you'll eventually skip a month, and a skipped month means your growth trend line is lying to you. We wrote a full breakdown of where this approach holds up and where it breaks in SoleOS vs a spreadsheet.

Option 2: connect each source and let it aggregate

The alternative is connecting Stripe and RevenueCat (and App Store Connect / Play Console directly, if you have projects not routed through RevenueCat) to something that pulls the data on a schedule and normalizes it for you. This is the approach we built SoleOS around, so take the following with that in mind: SoleOS connects to Stripe, RevenueCat, App Store Connect, and Google Play, aggregates MRR per project using a documented formula, and shows the portfolio total alongside each project's number — read-only, OAuth-based connections, detailed in what SoleOS connects to.

Disclosure: SoleOS is a product built by the person writing this post, and it's exactly this category of tool — so weigh the recommendation accordingly.

Where this approach earns its cost: once you're past 3-4 revenue sources, or once you're checking MRR often enough that a manual pull becomes friction you actively avoid (which shows up as you just... not checking, and finding out about a churn spike three weeks late). Where it doesn't: if you have one product, or if your billing is simple enough that Stripe's own dashboard already gives you the number you need. Stripe's built-in MRR view is genuinely good for a single project — don't add a tool to solve a problem you don't have yet.

What "one dashboard" should actually show you

A portfolio MRR view is only useful if it does more than sum numbers. At minimum it should show:

• Per-project MRR and the portfolio total, so you can see which products are carrying the rest.
• Month-over-month trend, not just a snapshot — a single number tells you nothing about direction.
• New vs. churned vs. expansion MRR if your connectors support it, since a flat total can hide a product that's losing customers as fast as it gains them.
• Currency normalization, if any project sells internationally — a raw sum across currencies is meaningless.

If you're running Stripe and RevenueCat side by side and want the mechanics of keeping both in sync without double-counting or missing store-specific events, we go deeper in tracking Stripe and RevenueCat together.

A worked example of the normalization problem

Say Project A (web, Stripe) shows $1,200 MRR from monthly plans plus $600/year in annual plans. Project B (mobile, RevenueCat) shows $900 in "current subscriber revenue" for the month, which includes some users in a grace period who may or may not renew. Naively adding $1,200 + $50 (the annual divided by 12) + $900 gives you $2,150. But if Project B's grace-period users don't renew, your real number is lower, and if you didn't decide up front how to treat annual plans, someone else on your team (or future-you) might compute Project A differently next month. The dashboard isn't wrong because of bad math — it's wrong because nobody wrote down the rule.

This is the actual argument for centralizing MRR tracking, tool or spreadsheet: not the visualization, but forcing yourself to pick one definition and apply it everywhere.

Frequently asked questions

Does MRR from RevenueCat match MRR from the App Store or Play Console directly?

Not exactly. RevenueCat computes its own normalized MRR based on active subscriber events it receives, which can lag or differ slightly from the store's own reporting due to timing, refunds, and grace-period handling. If you need store-of-record accuracy, reconcile periodically against App Store Connect or Play Console rather than treating RevenueCat's number as final.

Should I count trialing users in my portfolio MRR?

Most founders exclude trials from MRR and track trial-to-paid conversion as a separate metric. Including trials inflates the number and makes it harder to see real committed revenue — pick one convention and apply it to every project so the portfolio total stays comparable.

How often should I refresh a portfolio MRR dashboard?

Monthly is the minimum for spotting trend direction; weekly is more useful if you're actively iterating on pricing or acquisition. The frequency matters less than consistency — an irregular refresh schedule makes month-over-month comparisons unreliable regardless of the tool.

What if one of my products doesn't use Stripe or RevenueCat at all?

Then it sits outside whatever automated aggregation you build, and you'll need to add it manually or find a connector that supports its billing system. Check what's actually supported before assuming a tool will cover every project — see what SoleOS connects to for the current list, since coverage varies by tool and changes over time.

Is a paid dashboard tool worth it for two products?

Usually not. Two products with simple billing are easy to check by opening two tabs. The value of a unified dashboard grows with the number of revenue sources and the pain of checking them manually — see real numbers from a 10-app portfolio for what that looks like at higher counts, and the live demo if you want to see the aggregated view before deciding either way.