I would counter with stack overflow which has scaled great over all this time on only a few self-hosted servers.
The trouble with replacing the buy with a diy later on is that it will now cost at least twice as much to build, because 1) you're maintaining the existing system which takes some of the people most familiar with the problems of the existing system, and 2) the existing system will still evolve a bit because that's business, so you're also trying to hit a moving target.
I think other posters have it correct, you have to think hard about how central a particular feature or service is to your business model. Chances are, differentiating yourself means off the shelf solutions won't be a perfect fit for your core revenue, but all other supporting services should probably be off the shelf.
Replacing a managed solution in a small-scale product really isn't required, because it likely doesn't cost you enough. Replacing it in a high-scale product does matter, but that also mean you should be making enough money to make the replacement pay for itself. If you make the decision to use the managed solution and it's wrong, that's something you can usually fix. If you go DIY when you should have paid for it - you rarely get to correct it in time, and it might just be another nail in your coffin due to lower velocity, focus, etc...
If I could do it all again, I would have gone cloud-native (or at least leveraged K8s), and I'd use as many managed cloud services as humanly possible. At a later gig - we did just that, and we very very rarely had even 1% of the infra struggles we had with the solution I described above.
Nowadays, my basic advice is to always buy the best possible service when you start out, and only start to think about replacing it with DIY services when you have enough scale to pay talented engineers a salary to build AND support replacing it - and even then, the potential loss of focus and velocity might still make this a bad idea. There's a reason Netflix is still on AWS.