For me sometimes the cloud is a pain in the ass when the script can run locally. If I were doing a project which largely involved data scraping for personal use or as a stepping stone to something else, good chance I'm running it on my own machine.

The cloud is ultimately just about hardware. You are running your code on someone else's hardware because either you don't want to run it on your or you don't have enough of your own hardware to do so.

Now, lets assume the answer is that you don't want to use your own hardware, for whatever reason, and will be running your code on someone else's hardware. In addition to the money cost ($-cost) you will be paying for that hardware there is also the time cost (T-cost) and complexity cost (C-cost).

T-cost represents the effort it will take to get your solution running on someone else's hardware. This can be as simple as a few config changes and deploy scripts but can also involve custom code. Depending on your architecture the T-cost could be a one-time constant or could scale with your entire solution.

C-cost represents the effort it will take to make any changes to your solution because it's running on someone else's hardware. You want to add a new feature and if your solution was a single program running on your desktop it would take X time, but because it's a distributed system running on an unknown number of someone else's hardware it takes twice as long to do.

T-cost mostly comes from optimization. You can take a solution that runs on your dev box, put that in a single VM and run it on someone else's hardware and it will work. But it doesn't scale much and you are paying a constant $-cost regardless of how much it is used. Making your solution scale generally requires breaking it up into smaller components that can be scaled separately. There are other optimizations you can make, often vendor specific, that can improve your solution's performance but are only available because (and were probably caused from) you are running on someone else's hardware.

C-cost scales with T-cost. If you do little-to-no optimization for running on someone else's hardware then there is no real impact to your solution and you will be just as productive as when everything was running on localhost. So all the effort you put into T-cost to improve your scalability/performance/$-cost comes with an additional cost of C-cost.

Now there are two processes you can follow to get to a cloud solution.

1. Start it from the beginning as a cloud solution
2. Start it as a "normal solution" and then at some point in the future migrate it to a cloud solution.

The vast majority of the time option 2 is the correct way to go. Why? Two reasons:

1. Get to market. You will get a usable solution much faster and get feedback earlier to improve it...or maybe cancel it because you learn your solution was based upon incorrect assumptions.
2. You original assumptions around how much you needed a cloud solution were wrong. What if running a single VM is actually sufficient for your solution's needs? What if you only needed to optimize one part of your solution, rather than make everything horizontally scalable? Cloud solutions are all about optimization and unless you know a LOT about a problem you should almost always get a simple solution first and then optimize as needed.

One of the great things about modern software tools is that with containers you can easily deploy your dev environment to run on someone else's hardware. So even for the cases where you could run on your own hardware but choose not to (aka almost every personal project that needs to be internet accessible) you can still have your cake and eat it too.

TLDR: You won't know how much cloud vendor features you need you have a working solution running in the cloud, so get a working solution first and then worry about the cloud.

If you are doing a company project, I don't assume you would have many choices. If it is a personal/side project I would recommend not going cloud unless you use something so easy and seamless to get started like Google Cloud Run (your app will need to be dockerized). Another quick getting started would be to do a personal account on Vercel (formerly Zeit). If you get some traction and users then think of scaling up to a cloud.

When targeting clients that will only trust you if they have everything on-premise.
Maybe the number for those are shrinking but you would be surprised to see how many still do it.

Also, some people just want you to distribute them code or an executable and they can use it, or deploy it on their on machines or clouds when they need it.

When you need lots of compute power. Typically most cloud providers will burn a massive hole in your account if you're doing something intensive, video processing for example, at which point it would be cheaper in the long run to either use dedicated servers, or co-locate your own build. Jeff Atwood has written an article about this [1]. He basically comes to the conclusion that in the long run BYOH (Bring your own hardware) is cheaper than relying on cloud providers. Of course, the trade off being that you would then need to be responsible for managing said hardware.

[1] - blog.codinghorror.com/the-cloud-is...

Cloud is a bit of a PITA for testing (though Google App Engine had a local server already way back in the day) so I tend to use cloud for deployment, not for development. I'm fully aware people might not share my view and I welcome tools like GitPod, Cloud9 and the future GitHub Codespaces to bring back some of that "local development" feeling in a cloud setting

If you consider cloud just as a hosting provider than I don't think there's a place where I personally worked and it wouldn't fit in the cloud. However couple of things regarding companies that mostly dominate the "cloud" and this is not technical but rather legal:

1. one client/customer can't host on AWS - some legal stuff
2. some required hybrid solution as their data needs to be stored on their servers
3. some required servers to be in a specific country to comply with their own laws - not all countries are offered by the cloud people, and a lot of times company from let's say USA has to give access to their government even if you thing your data should be protected by country where the servers are, too much legal stuff here I really wouldn't like to worry about but you have requirements from customers/clients
4. cloud solutions have more and more SaaS which might be direct hit on your solution so if you host on such cloud provider there's couple of issues to consider

Hope I could broaden the business picture instead of just focusing on tech complications

The main thing to be aware of is to not use an AWS service just because it is "shiny". But its also nice to be able to spin up something quickly that otherwise you would need to spend hours or make real monetary commitment like hosting your on box in a server farm with a fixed contract.