Build for today's needs but have a notional roadmap for how to scale your architecture as the company grows. The author is mostly correct that K8 is complete overkill for most early/mid stage companies and startups, however extensibility is a key architectural concern and one that cannot afford to ignored at the outset. If you need to re-write large amounts of code from scratch every time your business scales up that's a good sign that you aren't thinking far enough ahead. For instance here are some straight-forward things you can probably do today that require little additional effort but will make a migration to k8 much less painful down the road (should you ever get there): 1) Use domain driven design to properly abstract your code 2) Make services and auth stateless where-ever possible/practical 3) Containerize your codebase and leverage a container registry as part of your CI/CD process

BLUF always have both a current state architecture as well as a future state architecture in mind and a plan for how to gradually evolve from one to the other over time.