Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stripe Data vs. Open‐Source Alternatives: A MRR Example

github.com

Post reply on HN
Print view View original

11–20 of 75 posts

Re: Stripe Data vs. Open‐Source Alternatives: A MRR Example

#11

Post by danpalmer »

peterldowns wrote: post #6
danpalmer wrote: post #3

At my previous company we used Stripe, and never saw any value in their data products. I was always curious as to why they had data products and would be interested to hear the other side – satisfied users with solved use-cases. The reason it always seemed weird to me is that billing data is just one small portion of a company's data. We had all sorts of data about our users – preferences, demographics, data from mar…

Some businesses are large enough that polling the API and/or ingesting webhooks is a poor architectural choice or simply impossible — Sigma and the other bulk data products are extremely useful for these businesses. The other kind of business that benefits from Sigma is much lower tech than yours, and most likely doesnt have a database or something that can accept webhooks.

Is that true? Polling the API might be too much, but I would expect Stripe to be able to handle a few GETs for every payment they take, even big companies will probably only be taking ~1-10k payments/second, doubling or tripling that isn't much. And ingesting webhooks for payment is necessary to be able to perform access control or whatever is necessary for the business to function. Conversely, $0.03 of margin to patch over bad engineering is quite a lot of margin for some types of business.

Lower tech businesses perhaps, but most of them probably aren't doing data analysis anyway.

Re: Stripe Data vs. Open‐Source Alternatives: A MRR Example

#12

Post by peterldowns »

danpalmer wrote: post #11
peterldowns wrote: post #6

Earlier quoted context omitted.

Some businesses are large enough that polling the API and/or ingesting webhooks is a poor architectural choice or simply impossible — Sigma and the other bulk data products are extremely useful for these businesses. The other kind of business that benefits from Sigma is much lower tech than yours, and most likely doesnt have a database or something that can accept webhooks.

Is that true? Polling the API might be too much, but I would expect Stripe to be able to handle a few GETs for every payment they take, even big companies will probably only be taking ~1-10k payments/second, doubling or tripling that isn't much. And ingesting webhooks for payment is necessary to be able to perform access control or whatever is necessary for the business to function. Conversely, $0.03 of margin to pat…

Yes, it’s true. For a hint of some of the utility and complexity, consider backfilling historical data; or, how you’d ensure consistent views (as of time X) of historic data (all charges before time X) when each row in the dataset is mutable.

Re: Stripe Data vs. Open‐Source Alternatives: A MRR Example

#13

Post by peterldowns »

AnhTho_FR wrote: post #9
peterldowns wrote: post #4

I used to work on Sigma/ReportingDataPlatform, and all I’ll say here is that this article is wildly off base with regards to utility and cost — the DoorDash examples are laughable. The article is correct that calculating MRR is difficult and requires access to your billing data. I am very skeptical that working with data provided by Lago makes it any easier than working with the data you can get from Sigma or from da…

The question is: how can we (Lago) make it much easier (if you think it's not the case today) than working with the data from Sigma and from data pipeline exports?

I don’t think you can, which is why I criticized this blogpost for failing to demonstrate a compelling answer, and instead relying on misleading arguments based on invalid pricing assumptions.

If you think it’s easier to calculate MRR with Lago than with data derived from Sigma or the reporting data exports, I suggest showing how it’s done in each case and explaining why Lago’s schema makes it easier.

Arguing that it’s harder on Stripe because if you’re DoorDash you would have to pay a lot of money for Sigma is not honest.

Re: Stripe Data vs. Open‐Source Alternatives: A MRR Example

#14

Post by AnhTho_FR »

peterldowns wrote: post #13
AnhTho_FR wrote: post #9

Earlier quoted context omitted.

The question is: how can we (Lago) make it much easier (if you think it's not the case today) than working with the data from Sigma and from data pipeline exports?

I don’t think you can, which is why I criticized this blogpost for failing to demonstrate a compelling answer, and instead relying on misleading arguments based on invalid pricing assumptions. If you think it’s easier to calculate MRR with Lago than with data derived from Sigma or the reporting data exports, I suggest showing how it’s done in each case and explaining why Lago’s schema makes it easier. Arguing that it…

I'll reach out in DM re: invalid pricing assumptions (genuinely wand to gather feedback and iterate). Re: "how it's done with Lago" : I assume you've seen the SQL queries we shared as examples... but you still don't think it makes the point, what would have? https://github.com/getlago/lago/wiki/Stripe-Data-vs-Open%E2%...

Disclaimer: the example (for the sake of the article) is relatively simple, as it's our first article on this topic, but we're willing to go much deeper, so feedback/inputs are welcome.

Re: Stripe Data vs. Open‐Source Alternatives: A MRR Example

#15

Post by fsndz »

peterldowns wrote: post #4

I used to work on Sigma/ReportingDataPlatform, and all I’ll say here is that this article is wildly off base with regards to utility and cost — the DoorDash examples are laughable. The article is correct that calculating MRR is difficult and requires access to your billing data. I am very skeptical that working with data provided by Lago makes it any easier than working with the data you can get from Sigma or from da…

I have to agree here. Feels like pure marketing/selling blogpost. I was not convinced.

Re: Stripe Data vs. Open‐Source Alternatives: A MRR Example

#16

Post by fsndz »

peterldowns wrote: post #12
danpalmer wrote: post #11

Earlier quoted context omitted.

Is that true? Polling the API might be too much, but I would expect Stripe to be able to handle a few GETs for every payment they take, even big companies will probably only be taking ~1-10k payments/second, doubling or tripling that isn't much. And ingesting webhooks for payment is necessary to be able to perform access control or whatever is necessary for the business to function. Conversely, $0.03 of margin to pat…

Yes, it’s true. For a hint of some of the utility and complexity, consider backfilling historical data; or, how you’d ensure consistent views (as of time X) of historic data (all charges before time X) when each row in the dataset is mutable.

can't you just design your database so as to be able to do that independently ?

Re: Stripe Data vs. Open‐Source Alternatives: A MRR Example

#17

Post by echelon »

fsndz wrote: post #15
peterldowns wrote: post #4

I used to work on Sigma/ReportingDataPlatform, and all I’ll say here is that this article is wildly off base with regards to utility and cost — the DoorDash examples are laughable. The article is correct that calculating MRR is difficult and requires access to your billing data. I am very skeptical that working with data provided by Lago makes it any easier than working with the data you can get from Sigma or from da…

I have to agree here. Feels like pure marketing/selling blogpost. I was not convinced.

Try hooking Stripe up to any third party analytics dashboard. You won't get an accurate MRR.

It really sucks if you want to have Stripe metrics in front of your team.

Re: Stripe Data vs. Open‐Source Alternatives: A MRR Example

#18

Post by Rafsark »

ripe wrote: post #10

For people like me who might be wondering: MRR = monthly recurring revenue This is a metric relevant to subscription businesses.

Yes! And ARR = annual recurring revenue. In addition to other saas metrics like usage revenue that is pure consumption based and sometimes calculated differently

Re: Stripe Data vs. Open‐Source Alternatives: A MRR Example

#19

Post by Rafsark »

fsndz wrote: post #16
peterldowns wrote: post #12

Earlier quoted context omitted.

Yes, it’s true. For a hint of some of the utility and complexity, consider backfilling historical data; or, how you’d ensure consistent views (as of time X) of historic data (all charges before time X) when each row in the dataset is mutable.

can't you just design your database so as to be able to do that independently ?

You’ve got plenty of paid options with Stripe, but here’s the catch: trying to match what you see in the Stripe dashboard with exact cent accuracy using queries is a total headache. in addition, it would be simpler to add an option to pull that data via an API call.

Re: Stripe Data vs. Open‐Source Alternatives: A MRR Example

#20

Post by guyfromfargo »

danpalmer wrote: post #3

At my previous company we used Stripe, and never saw any value in their data products. I was always curious as to why they had data products and would be interested to hear the other side – satisfied users with solved use-cases. The reason it always seemed weird to me is that billing data is just one small portion of a company's data. We had all sorts of data about our users – preferences, demographics, data from mar…

I consult in this space, and Sigma is one of my favorite tools. It can be useful specifically for fighting delinquent churn. One of the first things I like to check is to see if a particular card brand is declining more than others. I also like seeing the average time between the first failed payment and success. There is all sorts of data in Stripe that can help create a strategy for combating delinquent churn.

Sure you could get and store all of this data from webhooks and into the database, but most product teams don’t want to spend the time implementing this. Keep in mind it’s usually the finance/revenue team that needs this data. They’d rather pay Stripe a couple hundred/thousand dollars and get the data instantly, rather than bugging the product team only to find out the ticket got back burnered.

Post reply on HN