Live data from Hacker News

I Replaced Baremetrics and ChartMogul with Rake

keygen.sh

21–30 of 39 posts

Re: I Replaced Baremetrics and ChartMogul with Rake

#21

I'd be cautious multiplying your MRR x 12 to establish ARR. Things like seasonality or promotions could overestimate your ARR by using inflated subscription numbers. Additionally, if customers are not contractually obligated to stick around for a year, that calculation may not account for month-to-month churn.

I’m pretty comfortable with MRRx12 for annual run rate, which is pretty normal from what I’ve seen. But I do have other unmentioned revenue forecasting metrics based on current/past growth/churn rate, which I pay more attention to than my ARR. I don’t base a lot on this number either way.

Re: I Replaced Baremetrics and ChartMogul with Rake

#22

I'd be cautious multiplying your MRR x 12 to establish ARR. Things like seasonality or promotions could overestimate your ARR by using inflated subscription numbers. Additionally, if customers are not contractually obligated to stick around for a year, that calculation may not account for month-to-month churn.

ARR is always MRRx12.

You're talking about a revenue model.

Re: I Replaced Baremetrics and ChartMogul with Rake

#23

I never found the right solution (ChartMogul has issues with when they recognize revenue. It's based on payment instead of the period the invoice/subscription is for). Anyone have any tips to share about what they use?

Like OP, a very small script that actually understands accounting.

Re: I Replaced Baremetrics and ChartMogul with Rake

#26

I'd be cautious multiplying your MRR x 12 to establish ARR. Things like seasonality or promotions could overestimate your ARR by using inflated subscription numbers. Additionally, if customers are not contractually obligated to stick around for a year, that calculation may not account for month-to-month churn.

ARR is always MRRx12. You're talking about a revenue model.

I think the confusion here stems from the terms "annual run rate" and "annual recurring revenue" sharing the same acronym

Re: I Replaced Baremetrics and ChartMogul with Rake

#28
post #27

Your Ruby ActiveRecord query is so under optimized, you are loading a ton of records that instantiate objects and then apply a filter on this huge array. I'm pretty sure you could make it 100x faster.

I don't think those are ActiveRecord queries, they look like calls to the Stripe api via the Stripe gem. It's possible those filters like 'deleted?' are not able to be applied when querying the API.

Re: I Replaced Baremetrics and ChartMogul with Rake

#29
post #27

Your Ruby ActiveRecord query is so under optimized, you are loading a ton of records that instantiate objects and then apply a filter on this huge array. I'm pretty sure you could make it 100x faster.

I don't think those are ActiveRecord queries, they look like calls to the Stripe api via the Stripe gem. It's possible those filters like 'deleted?' are not able to be applied when querying the API.

Correct. Those are Stripe API calls made through their client library.

Re: I Replaced Baremetrics and ChartMogul with Rake

#30
post #20

I keep hearing that people aren't getting everything they want out of Baremetrics. What is it that they have a problem with?

> What is it that they have a problem with? We struggle a lot with “fake churn” in baremetrics. By that, I mean any time a customer on a credit card subscription upgrades to a “pay by invoice” tier, it shows as a churn of the credit card subscription and as new revenue for the invoice subscription. This makes churn wildly inaccurate and we spend a couple hours per month adjusting the numbers to get accurate data. FWI…

In many cases you should try to bill everyone out of the same billing system. For example, you can still invoice customers out of Stripe - you just disable the option to pay with a credit card.

Or are you saying you do that already and it still shows up as churn?

Post reply on HN