Just that a simple stack that's boring can work well for a SaaS whose success is not contingent on huge traffic.
For many successful SaaS companies, if their model is not monetizing huge traffic through ads, traffic is really not a metric of success. And they can be financially successful handling only paltry traffic.
Lots of business-problem-solving apps fall into this space. Sure, maybe you only have 60 customers using your app. But if each one is paying you $1,000 a month...
Nope, just different. I'm a big proponent of the notion of 'innovation tokens,' which has come up elsewhere in this discussion[1].
If the project that I was referring to had been a 'just for me, just for learning' side project, I would have chosen one new-to-me technology. It might have been some JavaScript SPA framework. It might have been Kubernetes. Or maybe GraphQL. It might have been something completely different.
But, this project was absolutely critical for its users, and it had to be delivered on an incredibly tight timeline. I didn't have the luxury of playing around with anything new. And this is still the case. In fact, the project has grown in importance for its users and I have even less flexibility to play around with new-to-me technologies right now.
---
[1] Here's an example of me discussing this six years ago, although I was unfamiliar with the term at the time: https://news.ycombinator.com/item?id=9291437 ... Re-reading this comment, I'm actually kind of surprised how little I disagree with here. The only thing that has actually changed for me is that I use Swift instead of Objective-C for my iOS apps.
Starting with an easily scalable infrastructure, if the need for a scalable infrastructure is either unproven or distant, is not the best use current resources. It's more cost-effective and beneficial to use an out-of-the-box tool like Heroku and spend our time building the product that people will actually be paying for.
There might come a time where the hosting costs on Heroku are getting frighteningly high, but even then it's something that might not be high priority. If the profit impact of building and maintain a K8 infrastructure is less than the profit impact of building a new feature and securing more users, then by all means, let's continue paying Heroku and focus on what makes the business more sustainable.
The time to convert from a simple setup like Heroku to a scalable system like K8 is when that change has the biggest net impact on the company's operation.
