Very real example coming up. I was one of 3 engineers with a "day one" start-up just over 2 years ago. I was dedicated to infrastructure, and have experience with hardware > OS > config management > orchestration > CICD > monitoring. I've deployed hashicorp stack and Kubernetes. I've managed in-house services like gitlab, database clusters, metrics/logs solutions, Jenkins etc. I've also managed firewalls and I'm rusty on switches etc but I've done that too.
At the start-up we ran nothing ourselves, except the gitlab runners. (Well, except for the first month where a bunch of laptops are used to prototype the app). I spent my first year writing terraform and helping design the product for low-cost scalability. So much of what we did for that whole year was in the free tier that our runway money could cover team building. 1 year in, I could deploy our entire stack from scratch into a new region in under an hour. VPC, subnets, security rules, IAM, queues, workers, Kubernetes cluster with autoscaling nodes, databases, DNS, CDN, monitoring, metrics, email (AWS SES)...
That type of fast deployability to a new region shouldn't be a late consideration after you've spent a year tinkering with in-house stuff. In fact, getting to another round of funding requires that you have that stuff ironed out. Can you support FedRAMP requirements? Yes, because that was a day one consideration. How about GDPR? Ditto. Do you have separate dev, test and prod environments which are identical apart from scale/cost? Yep!
Right now I'm working with a company that built everything in-house, from the perspective of "one single data center". It's a disaster. If you're not thinking at scale from the start, your probably not doing basic stuff like proper naming conventions, non-clashing CIDR. They're using all the right tools, but badly. Their terraform is a mess because it was obviously introduced it gradually on top of existing "snowflake" infrastructure. Their next data center was pretty much copy-paste followed by a thousand changes. And their code coverage is low - lots of stuff still manually created. (This is a known company with a decent product and lots of customers!). All of the people hired to try to make it scalable after the fact are saying things like "...it would be easier to just throw it all out and start over".
The problem with doing things badly because you think you can improve it later is that suddenly you've got customers on this thing, and you can't start over.