[Scotrix]

As a developer I’m always surprised that these issues are real.

I’m used to store raw data I receive back from payment processing in my own database as transactional events (e.g. renew, cancel, successful and failed payments ) ends up as single events. I do the same for all application events and it is then rather easy for me to get the data as I need it for whatever KPI I want (activity, retention, usage) and for very little overhead while building products.

So I’m wondering, is this a result of all the low-/no-code stuff going on?

[rtpg]

Often the database structure that is amenable for running the app or billing system isn't the one that is ammenable for generating a graph of historical MRR over your company's lifetime (or future expected revenue!)

And when you get into cohort analysis, it gets a bit messier. Your cohort calculations might be cheap on one user but not across your entire system.

This is often just a question of some very simple data engineering. But you get queries that are "good enough" and "basically are right". So you use them. And they get slower and slower until they take like 10 minutes to run because you're calculating historical app usage data for your bespoke cohort. And then they start taking hours. And then they're just timing out constantly. And then you start fundraising and you do "MRR/ARR vs actual money in/out", and find weird discrepencies (yes you included one-time purchases. Or did you? And your rebates done through the stripe dashboard definitely were captured in your app database right?)

Oh and of course your top sales person has been giving people discount coupons but they were doing it in Stripe instead of in your bespoke system and you weren't properly flowing the data back into your system because of webhooks and now you realize that your MRR is 5% less than it actually is (and it's been like this for 2 years so now you have lied to investors consistently for 2 years).

Nothing is really hard, but it's too easy to get a "close enough" answer and the activation energy to doing this stuff right is just high enough to where people put it off for way too long.

[figassis]

Partly. There is always some data you will need in the future that you don't think to store today. So I suspect MRR is not the only issue these startups are having. Another example is stripe just does not make some fields available via api. Say, the date an external account was added to a connected account. That is not in the api, so if you then want to add some logic that depends on the age of certain accounts (maybe fraud prevention), you're out of luck. You would have to handle the event when it happened, and use the current time. But Stripe does show this date on the UI.

[paulddraper]

....that's exactly what the article is describing.

Retrieving the metrics you want from raw data.