How to Track Revenue Across Multiple SaaS Projects (Without Drowning in Stripe Tabs)
Here's a scene that plays out every month for anyone running multiple side projects. Stripe dashboard for project A — open. Stripe dashboard for project B, different account — open. Gumroad for that one digital product — open. RevenueCat for the iOS app — open. Now copy all those numbers into a spreadsheet. Try to remember what currency each one is in. Realise the spreadsheet hasn't been updated since October. It's Wednesday before you have any idea how last month actually went.
If you're trying to track revenue across multiple SaaS projects, this is probably your life right now. And it doesn't scale.
The indie hacker portfolio model is increasingly popular for good reason. Running two, three, five small products spreads your risk and gives you optionality. But the operational side of it — particularly the financial tracking — is a mess that nobody really talks about until they're deep in it.
The fragmented revenue problem
The root issue is simple: every product lives in its own financial silo. Stripe doesn't know about your Gumroad sales. RevenueCat doesn't know about your web subscriptions. Each platform has its own dashboard, its own reporting period, its own way of presenting numbers. And none of them can answer the question that actually matters: "what is my total MRR right now, across everything?"
This gets worse the more successful you are. By the time you're running four products across three billing providers, you're spending real time every month just assembling numbers into something legible. That's time you could spend building.
Why MRR is the number that matters
MRR — monthly recurring revenue — is the recurring baseline of your business. Not "revenue this month." Not "total sales." MRR. It tells you what to expect next month if nothing changes, stripping out the noise of one-time purchases, annual payment spikes, and refund timing.
Calculating MRR gets complicated when your products have different billing models. Monthly subscribers are straightforward — their monthly payment is their MRR contribution. Annual subscribers need to be divided by 12. One-time purchases technically aren't recurring at all, though some people amortise them over an expected lifetime.
The important thing is to be consistent. Pick a method, apply it across all your projects, and stick with it. When you're trying to calculate MRR across multiple products, consistency matters more than precision within any single one.
Multi-currency is where it gets painful
This is the part that spreadsheets handle worst. One project charges in USD because the audience is American. Another charges in GBP because it started as a UK-focused tool. Maybe a third is in EUR.
So what's your total MRR? £1,200 + $800 + €350 = ... what, exactly?
You need to convert to a base currency. Fine. But which exchange rate? Today's rate? The rate on the day each payment was made? The average rate for the month? There's no perfect answer, but there is a practical one: use today's rate for your dashboard view (so you always see a current picture) and lock the rate at end-of-month for your historical records.
Spreadsheets can technically do this, but in practice nobody maintains live exchange rate lookups in Google Sheets for more than about two months before the formula breaks or the API changes. It's one of those problems that's simple in theory and maddening in practice, and it's a big part of why indie hacker revenue tracking across multiple projects falls apart.
The spreadsheet trap
Spreadsheets deserve their own section because almost everyone starts with one, and almost everyone eventually abandons it.
The lifecycle goes something like this. Month one: you set up a beautiful sheet with columns for each project, rows for each month, formulas for MRR calculation, and a nice summary at the top. Month two: you update it on time and feel virtuous. Month three: you're busy shipping a feature and forget to update until the 15th. Month four: you update it but get one formula wrong and don't notice. Month six: you realise that annual subscription from project B has been counted as monthly revenue for three months, inflating your MRR by 40%. Month eight: you haven't opened the sheet since June.
This isn't a discipline problem. It's a tooling problem. Manual data entry for financial tracking doesn't work long-term because there's always something more urgent than updating a spreadsheet. And when the spreadsheet is always a month behind reality, it stops being useful, so you stop looking at it, so it falls further behind. It's a death spiral.
The Stripe dashboard for multiple accounts problem makes this worse. If all your revenue was in one place, maybe you could live with checking it directly. But when you need to log into three separate Stripe accounts, plus Gumroad, plus RevenueCat, to assemble your MRR — that's a workflow that's begging to be automated.
Expenses are half the picture
Revenue gets all the attention. But a project making £500/month that costs £400/month to run is a very different proposition from one making £300/month that costs £20/month. Without tracking expenses alongside revenue, there's no way to know which projects are actually making money.
The expense list for a typical SaaS project is longer than most people think. Hosting (Vercel, Railway, Fly, AWS). Database (PlanetScale, Supabase, RDS). Domain registration. Transactional email (Resend, Postmark). Error monitoring (Sentry). Analytics. Any third-party APIs with usage-based pricing. Authentication providers. CDN costs. And the SaaS tools you use to build and run the thing.
Multiply that by four projects and you've got potentially dozens of line items across multiple billing cycles. Some are monthly, some are annual, some are usage-based and vary month to month. Tracking profit across side projects requires capturing all of this, not just the revenue side.
What you actually want is a per-project P&L. Project A: £500 revenue, £120 expenses, £380 profit. Project B: £300 revenue, £280 expenses, £20 profit. Now you know where your time is best spent — and which project might not be worth maintaining.
What a proper multi-project revenue view looks like
The ideal: one screen showing every project, its current MRR, month-over-month growth, expenses, and profit. A total portfolio MRR number at the top. Trend lines showing which projects are growing, which are plateauing, which are declining. All in your base currency, automatically converted. A unified revenue dashboard for SaaS — not a spreadsheet, not five browser tabs. One view that answers "how am I doing?" in under ten seconds.
The key is automation. For Stripe-based revenue, connecting via OAuth so data syncs without manual entry. Connect each Stripe account once, and from then on every payment, subscription change, churn event, and refund is reflected in your multi-project MRR dashboard automatically. This solves the "Stripe dashboard multiple accounts" problem cleanly.
When revenue data is always current, you actually look at it. When you actually look at it, you catch problems early — a spike in churn, a drop in new subscriptions, a pricing tier nobody's choosing. The data was always there in Stripe; the problem was that assembling it across multiple accounts took too much effort.
The weekly financial check-in
Here's the habit that ties it all together: five minutes, once a week, looking at the numbers.
Not a deep analysis. Just opening your SaaS portfolio revenue view and checking: is MRR up or down? Are expenses out of line? Is anything trending in a direction that needs attention?
Five minutes is enough because you're not assembling data — it's already there. This is the payoff of automating the tracking: the check-in becomes trivially easy, so you actually do it. Without a good dashboard, the weekly check-in takes an hour, so you skip it, so you end up surprised by bad news that was visible weeks ago.
What we built to solve this
This problem — fragmented revenue, no unified view, spreadsheets that rot — is why we built Shipchart. It's a multi-project MRR dashboard designed specifically for indie hackers and solo founders running a portfolio of products.
It connects to your Stripe accounts via OAuth, so revenue data syncs automatically. Every project gets its own MRR tracking, and the portfolio view shows the total across everything — converted to your base currency, updated in real time. You can add expenses per project, so the dashboard shows actual profit, not just revenue. Month-over-month trends are visible at a glance. Which project is growing, which is flat, which is silently costing more than it makes — all of it in one place.
It's the unified revenue dashboard for SaaS that spreadsheets promise but never deliver.
There's a free tier, so you can connect your projects and see the portfolio view without paying anything. We built it because we had the exact problem this post describes — multiple projects, multiple Stripe accounts, a spreadsheet that was always three weeks out of date — and we wanted something better. Turns out a lot of other people running multiple side projects wanted it too.
The actual bottom line
Tracking revenue across multiple SaaS projects shouldn't be a part-time job. The numbers exist — they're sitting in Stripe, in Gumroad, in RevenueCat. The problem is that they're scattered, they're in different currencies, and nobody's assembling them into a picture that's actually useful.
Get your MRR calculation right and keep it consistent across projects. Track expenses alongside revenue so you know your real profit. Automate whatever you can, especially Stripe sync. Convert everything to one base currency. And look at the numbers once a week.
The portfolio approach to indie hacking works. But only if you know how the portfolio is actually performing. Otherwise you're just running multiple businesses in the dark and hoping it all adds up.
Stop hoping. Start tracking.