MRR tracker
for indie hackers
Most founders do not need another pretty chart. They need an MRR tracker that keeps recurring revenue honest when subscriptions live across multiple products, multiple billing intervals, and more than one processor. That means separating one-time sales, normalizing annual plans, and making the final number trustworthy enough to share.
Recurring
$18.4k
One-time
$2.1k
Sources
2 live
Who this is for
You track subscription revenue manually in a spreadsheet every month.
Your annual plans distort MRR because nobody is normalizing billing intervals consistently.
You sell subscriptions and one-time products but still want one clean recurring revenue number.
You want a public proof layer without exposing invoices, customers, or raw processor dashboards.
What a serious MRR tracker has to get right
The phrase MRR tracker sounds simple until the business gets slightly more real. A founder launches with one monthly subscription, then adds an annual tier, then ships a second product, then runs a one-time launch. Now the number on the processor dashboard is no longer enough because the business has more moving parts than the processor's default report was designed to explain.
ChartMogul's MRR definition is useful because it forces discipline. The reference makes two things explicit: monthly plans contribute their monthly amount, and other recurring plans must be normalized by interval. It also states that one-time line items do not count toward MRR. That is the baseline any founder should use before trusting a recurring revenue graph.
Stripe's own subscription lifecycle documentation shows why the metric gets messy fast. Subscriptions can betrialing, active, incomplete, past_due, unpaid, or canceled. If a tracker treats those states as one giant revenue bucket, you do not have an MRR tracker. You have a self-esteem machine.
That is where Makerfolio fits. Instead of making founders manually reconcile recurring revenue in spreadsheets, it gives them one place to compare processor totals, keep recurring and non-recurring revenue separate, and connect the clean metric to a shareable proof layer like apublic builder profile.
What the tracker should show
| Layer | Why it matters |
|---|---|
| Recurring subscriptions | Count only recurring plans that represent ongoing monthly value. |
| Interval normalization | Turn annual, quarterly, and custom billing into a monthly amount. |
| One-time revenue split | Keep launches, templates, and one-off orders visible without inflating MRR. |
| Processor-level visibility | See which revenue comes from Stripe versus Polar before you aggregate it. |
| Public proof layer | Publish a verified total instead of recycling screenshots in launch threads. |
Verified citations
ChartMogul Help Center
“For monthly plans, MRR is the amount paid each month for the subscription. For all other plans, ChartMogul calculates MRR using the invoice amount and the billing interval defined in the plan.”Open source ↗
Stripe Docs
“Subscriptions can have the following statuses. The actions you can take on a subscription depend on its status.”Open source ↗
ChartMogul Help Center
“One-time (non-recurring) line items do not.”Open source ↗
Related pages
Revenue Dashboard for Indie Hackers
Broaden the view from one recurring metric to the whole revenue stack.
Stripe and Polar Revenue Dashboard
See the exact integration angle for the processors Makerfolio supports today.
How to Calculate Net MRR Across Stripe, Polar, and Lemon Squeezy
Use a stricter framework before you trust any recurring revenue total.
Best MRR tracker for indie hackers
A support article on what to evaluate before trusting any MRR tracker.
MRR glossary
Refresh the actual metric definition before comparing tools.
Best public builder profile
Turn a private MRR tracker into something you can actually share publicly.
Sources
Track recurring revenue with fewer lies
Create a Makerfolio account, connect your billing stack, and get one MRR tracker that keeps recurring revenue separate from launch cash, one-time sales, and screenshot theater.