Why bother fixing the software stack for accounts that aren't going to pay for it? Also, remember that Baremetrics imports your entire Stripe account. Every single event, from day one, so it can analyze and chart them. For any decently sized business this is a ton of data, let alone 1000 of them.
I agree with the parent poster. If you had a separate loosely coupled Stripe importer system you could process those Stripe event streams into the required aggregates via a queue. That way you save your precious web server resources for processing real-time web requests without the performance hit. We churned off BareMetrics because of those server and performance issues a while back.
>> If you had a separate loosely coupled Stripe importer system you could process those Stripe event streams into the required aggregates via a queue.
Sorry, but it's not quite that easy. Stripe has rate-limiting and paginates response data. Providing metrics like "churn growth rate" between 2 dates requires you have all the data every day. You can somewhat rely on webhooks but not for historical data prior to a customer's sign-up date. Oh, and Baremetrics has plenty of queues.
This is definitely one of those things which sounds like it should be so simple until you actually try to do it, and then run into the hundreds of corner cases which break only in production during your 3am batch downloads.
In theory, it should be "easy" to scale since each account is fully discrete. More accounts, add a few more "workers" to pull jobs off the queue and everything is happy. Even on the front-end each company is hitting their own private data set, their own indices, etc. So unless you are discovering individual data sets / companies that themselves have a couple orders of magnitude more events than you are prepared to process... Even still, the total number of discrete metrics, and the cardinality of the metrics doesn't change all that much just because event counts themselves (total billings) increase.
So I can definitely see from both perspectives here... why is something like this so hard to scale up? Best answer is because the real world presents challenges well beyond the theoretical complexity of the problem at hand.
b/c you'll have 1k paying customers sooner or later. if you can't scale, you won't have a viable business. Look, I'm not suggesting to throw away your entire stack. It's very likely that you spend few days, find out the bottle neck and fix it with a scaleable/distributed method. Computing is cheap, and will forever getting cheaper. Paying customers are rare, deserve deep appreciation.
Just sprinkle Distributed Scaling Magic on your servers and voila! Your problems are solved!
Nobody is saying scaling out to an additional 1k customers is easy. The great thing about scaling slowly is that you can grow into the problems and address them as they come up. Suddenly doubling your userbase, most of which will ultimately churn out without paying you a dime, and having to deal not only with the technical but also the support ramifications, is a recipe for failure. As the article says.
If your app is impossible to scale, then your pricing model isn't aggressive enough. You should have a proper margin to grow your business b/c it'll ultimately benefit your paying customers.
If it's not, someone else would happily figure out a way to take care of your customers.
It's not a pricing issue, it's a time issue. Scaling a production application like Baremetrics isn't a turn-key thing. They can't just up the number of dynos or whatever you're thinking it's like. It takes time, time they decided was better spent servicing paying customers and new trial customers, instead of customers that statistically would never pay them.
I'm not sure what we're disagreeing on, really. The blog post literally has "failure" in the subject. It was an experiment that didn't turn out well, thus they ended it and are now moving on.
