[marcosdumay]

Yes, you'll spend some 2 days setting all services, testing, setting backups and alerts, testing again. Add another day if you want redundancy.

And then, every 4 to 8 months you'll spend some 2 hours making sure everything is working right and up to date. If you get into another user-base class (like, from 100 to 1000, or from 1000 to 10000), you will spend all those 3 days again.

Compare that with cloud services, where you'll spend a week up-front, and 2 days at random when something changes. But well, that comes with the bonus of a much higher price and a slower development speed.

There is the safety to know that you can move between user-base classes without any cost. You'll just be taken by surprise when it actually happens and you discover that those 3 days are a rounding error compared to what it costs to update your software.

[cddotdotslash]

This comment reads as if you worked with the cloud in 2009 and haven't been back since. It doesn't take a week to setup a service. In fact, you could spin up everything you need in maybe an afternoon to get you a fully-working, TLS-backed API and website. From that point forward, everything is fully managed and you don't need to deal with Let's Encrypt binaries and stdout logs, etc.

Your first paragraph is exactly what the OP of the article did who is now writing about how it failed.

[madamelic]

And building on barebones keeps all options open.

If you go big and realize an IaaS solution is right, great, you are ready to go on to IaaS with no trouble

If you IaaS from the beginning, you've cornered yourself and have to build your way out.

[chii]

How are these scenarios any different from each other?

You are not ready to go IaaS with no trouble if you've already built your own. It's just as hard to do that as going from IaaS to your own custom infrastructure!