|
|
|
|
|
by rtpg
657 days ago
|
|
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. |
|