Here's a free, easy way to track your MRR

Here's a free, easy way to track your MRR

I was once pitching an investor who asked what our current MRR was. I returned to the traction slide in our deck and started to repeat the (modest) figure, but he stopped me: "Not what's in the deck from a couple weeks ago—I mean right this minute."

I bungled the response. Don't let it happen to you.

The reality is that in early stages of a SaaS startup, MRR is tricky. You're trying out a few different pricing models, a single customer churning can represent a huge percentage of your revenue, and, if you're lucky, your co-founder is adding new subscriptions you don't even know about.

There are tools like InsightSquared that can help with this, but as an early stage startup you probably aren't going to like the price tag. You can try to reconstruct things from your Stripe dashboard, but churn timing complicates the picture.

Without further ado . . .

The Faraday MRR Changelog

It's a simple, free Google Sheets doc that your team can share to keep a real-enough-time tally of MRR and customer count.


How to install

  1. Go here for the template
  2. Choose File ➞ Make a copy
  3. Fill in row 6 with your current effective MRR

How to use

The key thing is to add a new row every time something happens. If you add a customer and they later churn, don't delete the original row: add a new one. Check out the 2nd tab in the doc for examples.

  • What's the difference between Log date and Effective Date? The log date is whenever you add the row. The effective date is a little tricker: it's the date at which the change in MRR or customer count takes effect. If you close a deal, the effective date will probably be the same as the log date. If a customer on an annual plan notifies you halfway through the year that they won't be renewing, the log date of the churn is today, but the effective date is the last day of their annual billing cycle.

  • Should I ever change an old row? Probably not, unless you're correcting an old mistake, but even then I'd recommend against: just create a new row with the changes necessary to reconcile. Changelogs work best when they're (to borrow a programming term) immutable.

Bugs? Ideas?

Drop me a line at my first name at