If you run a SaaS product and someone asks "how's it going?", the answer should be a number. And that number should be MRR.
Not "revenue this month." Not "total sales." Not "we had a good week." MRR. Monthly recurring revenue. The amount of money you can expect to come in next month if nothing changes. No new customers, no churn, no upgrades, no downgrades. Just the recurring baseline.
This is the single most important number in a subscription business, and a surprising number of indie hackers either don't track it or track it wrong.
What MRR actually is
MRR is your monthly recurring revenue. It's the sum of all active subscriptions, normalised to a monthly amount. If someone pays you £10/month, that's £10 MRR. If someone pays you £120/year, that's £10 MRR (£120 divided by 12). If someone made a one-time purchase of £50, that's £0 MRR because it's not recurring.
That last point trips people up. A one-time sale is revenue, but it's not MRR. MRR only counts money that will come in again next month automatically. That's what makes it useful. It's a forward-looking number, not a backward-looking one.
Total revenue tells you what happened. MRR tells you what's going to happen.
Why it matters more than revenue
Revenue is noisy. A customer pays their annual subscription in January and your revenue for that month looks amazing. February looks terrible by comparison, even though nothing changed about your business. You run a lifetime deal and revenue spikes, then flatlines. You issue a refund and revenue dips even though your subscriber base is healthy.
MRR smooths all of this out. It shows the true trajectory of your business. Is it growing? By how much? Is it shrinking? When did that start?
Revenue can go up while your business gets worse (a big annual payment masking rising churn). Revenue can go down while your business gets better (you stopped doing one-time deals and focused on subscriptions). MRR doesn't lie like that. It's the signal underneath the noise.
For indie hackers running multiple SaaS projects, MRR is even more important because you need to compare projects against each other. "Project A made £800 this month and Project B made £400" means nothing if Project A's £800 includes a one-off annual payment and Project B's £400 is pure monthly recurring. Project B might actually be the healthier business.
How to calculate it
The basic formula is simple:
MRR = sum of all active monthly subscription amounts
For monthly subscribers, just add up what they pay. For annual subscribers, divide by 12. For quarterly, divide by 3.
Where it gets tricky:
Annual subscriptions. A customer paying £120/year contributes £10/month to your MRR. Not £120 in the month they pay and £0 for the next 11 months. This is the most common mistake. If you count annual subs at their full value in the month they're charged, your MRR graph will look like a heart monitor and be completely useless.
One-time purchases. These are not MRR. If you sell a lifetime deal, a one-time addon, or a digital product, that's revenue but not recurring revenue. Some people amortise one-time purchases over an expected lifetime (e.g. spread a £200 lifetime deal over 24 months), but honestly, it's simpler to just keep them separate.
Free trials. £0 MRR until they convert to a paid plan. Don't count them.
Discounted subscriptions. Count the discounted amount, not the list price. If someone is on a 50% discount paying £5/month instead of £10, their MRR contribution is £5.
Multi-currency. If you charge in different currencies, you need to convert to a single base currency. Use a consistent exchange rate (today's rate for the dashboard view, locked rate for historical records). This is one of the reasons spreadsheets fall apart for MRR tracking across multiple products.
The components of MRR change
Once you're tracking MRR, the next step is understanding what's driving it up or down. There are five components:
New MRR is revenue from brand new customers. Someone signs up and starts paying. This is the growth engine.
Expansion MRR is additional revenue from existing customers. Upgrades, adding seats, moving to a higher tier. This is the best kind of MRR because acquisition cost is zero.
Contraction MRR is the opposite. Downgrades, removing seats, moving to a lower tier. The customer didn't leave, but they're paying less.
Churn MRR is revenue lost from customers who cancelled entirely. This is the leak you're always trying to plug.
Reactivation MRR is revenue from customers who previously churned and came back. Nice when it happens, but don't count on it.
Your net MRR change for the month is: New + Expansion - Contraction - Churn + Reactivation. If that number is positive, you're growing. If it's negative, you're shrinking. Simple as that.
Common mistakes
Counting gross revenue as MRR. Stripe shows you a payment of £120. You add £120 to your MRR spreadsheet. But that was an annual subscription. Your MRR only went up by £10.
Forgetting about failed payments. A subscription is only active if the customer is actually paying. If their card failed and the subscription is in a grace period, you probably shouldn't count it. Stripe handles dunning (retry logic), but you need to decide how you treat those in-between states.
Ignoring currency conversion. If you have customers paying in USD, GBP, and EUR, you can't just add the numbers together. £100 + $100 + €100 is not £300 or $300 or any other number without conversion.
Not tracking MRR at all because "it's only a side project." If it makes recurring revenue, it has MRR. Tracking it takes five minutes and completely changes how you think about the business.
What good MRR growth looks like
This depends entirely on stage. A brand new product going from £0 to £500 MRR in the first three months is solid. A product at £5,000 MRR growing 10% month-over-month is excellent. A product at £20,000 MRR growing 5% month-over-month is still very good.
The thing to watch is the trend, not any individual month. Three consecutive months of declining MRR is a problem regardless of the absolute numbers. Three consecutive months of acceleration (growing faster each month) is a sign you've found something.
For indie hackers with multiple projects, portfolio-level MRR is what matters most. If your total MRR across all projects is growing, you're in good shape even if one individual project is flat. That's the whole point of the portfolio approach.
Track it properly
The easiest way to get MRR wrong is to calculate it manually in a spreadsheet. It works for month one, maybe month two. By month six the formulas are fragile, the currency conversions are stale, and you haven't updated it since March.
If your revenue comes through Stripe, connect it to something that calculates MRR automatically. If you're running multiple SaaS projects, you need a tool that aggregates MRR across all of them into one number.
This is one of the core things Shipchart does. Connect your Stripe accounts, and it calculates MRR per project and across your whole portfolio automatically. Multi-currency conversion, annual-to-monthly normalisation, month-over-month trends. The number is always current because it's syncing from Stripe, not waiting for someone to update a spreadsheet.
There's a free tier if you want to try it. But whatever you use, track MRR. It's the one number that tells you whether your SaaS is actually working.