Understand the problem space, understand the solution space, and try to find a fit, don't just grab your favorite hammer and start whacking away.
But I get what you mean.
The assumption that you want to scale into millions of users do not always hold;
The assumption that you need kubernetes to scale into millions of users (or that you will even want it) does not always hold;
The assumption that solving that problem from the start leads to a better outcome than waiting that the problem appears has "winning the lottery" odds of not being the opposite of the truth.
It's absolutely perfectly fine to scale to millions of users with yesterday's proven simple tech using the benefits of time passed. You got everything that was hard before in managed services, why start complicating the simplest part (stateless app servers) now that we've got everything served on a platter?
I reckon 99% of the apps HN talks about that needs to "scale" can do it with VMs behind a load balancer, a cache, and a relational database. All of these are now available as managed services. Not to mention that you now got tailor made languages for it like Go that compiles to a simple single binary for your VMs to just kick off. Use the progress instead of trying to be clever. I mean, if actually producing a product is the goal, rather than a vehicle to unnecessarily squeeze in the latest tech into. There's no need to make a big up-front investment in building a platform on top of k8s etc. Spend the time on the product instead. And if you turn out to be in the 1% that's a good problem to have, and no, it won't be over night, so you're fine.
Surviving the initial scaling is an horrible experience, full of technical gotchas. People that have seen that will naturally want to avoid it. The problem is that it's an irrational desire, because what they do to avoid it destroys most of their chances to even get there.
It looks like a manifestation of the second system syndrome.
Unless you are building something that can kill people if it goes wrong just get it out the door and be as disciplined as you can along the way. If it is successful then you have the money to split it up into a SoA when you need it.
Please take effort and do quality stuff as if your life depends on it.
That is why I put in their “be as disciplined as you can be along the way”. If it never ships what’s the point; but if you ship something that has to be rewritten right away it’s almost as bad.
People who understand the problem space will eventually notice that kubernetes isn't a hammer but whole toolbox. So you can reach for it when you need a hammer, a different hammer, or a screwdriver, or when you're not sure what you need, or when you're 90% sure what you need but also willing to admit you might be wrong.
Not a universal panacea, but if we're going to get into this "right tool for the job" discussion, it's a complete misunderstanding to characterize it as a single tool.