But if the cost of having those things is low enough, maybe it's worth it to have them sooner rather than later.

I've experienced many of those tools in the context of a 200-person company; I can definitely see how managed versions of them could deliver value to a much smaller org.

Of course you don't "need" them. However, I don't believe I'm describing a large scale boilerplate. You can get this with a few servers and a couple hundred a month these days. Heck, you can do it on a laptop w/ minikube probably (though obviously not ok to do in prod, just goes to show the costs are not the problem here). Sure it's easy to run an app. But it's not easy to admin it as you grow (even though you are not yet "big" and still may be only one or two people).

Who will troubleshoot when shit hits the fan?

It seems to me that you are introducing technical debt from day one because it’s cool.

What technical debt?

The kind of technical debt otherwise known as premature optimisation. If you don't even know yet that your app has to scale - and in which way - preparing for that contingency is a waste of resources.

I wouldn't qualify that as a premature optimisation. Kubernetes is de facto standard of running applications now and you get all the benefits for almost free. Premature optimisation in this case would be over provisioning - throwing more servers than you need.

K8s is "de facto standard" already? When did that happen? No doubt that K8s has a great future and I personally like it a lot as well. But to call it a standard requirement itself is premature.