[ChuckNorris89]

>to build products or services that can practically run on it's own

No web service/app that is in the business of making money can just "run on its own", but needs constant development and maintenance. That's why the demand for web devs is so high. If every SW project would be a "fire and forget" experience as you claim, the career wouldn't be nearly as well paid as it is right now.

Even phone apps need to be updated or Apple/Google will remove them from the store.

SW in the '90's was more or less "fire and forget", but salaries and the demand then were nowhere near as high as they were to day.

[brnewd]

If you choose the right niche and use stable libraries there is no need to constantly chase the latest framework or software architecture. A lot of the endless development cycle is self induced work.

[ChuckNorris89]

Yeah sure, if you build a simple website/app for a mom&pop shop then yes, but the pay is equally poor and it's a race to the bottom.

Even in old cobol codebases coders are still needed to keep up with the changing environment.

The big money in SW is always made in apps and services that are scalable, and that needs constanrt engineering effort.

SW apps that aren't scalable, are a race to the bottom with low margins and low pay that has been offshored or replaced by the services of SW giants.

[brnewd]

You're not wrong, it is almost the default to end up with a high maintenance stack and the (perceived) need to churn out new features.

I've done a few hype driven migrations myself. But if you set out with the primary goal to reduce the amount of time required to run and maintain a software/SaaS/paas/you name it business you can make huge wins in the time department.

Maybe I'm just lucky with a niche subscription based platform that doesn't need much tuning and perhaps 10 support emails a day. It doesn't return a FAANG salary but does net me €90k with minimal operational costs.

The key is not build that app you don't really need (and indeed requires constant baby sitting to please Apple/Google) not rewrite everything to the latest fad eg Svelte + CockroachDB using edge compute on fly.io.

[throwawayscale2]

I.e., it's all made-up resume-driven development funded by woo-huffers with too much money that needs to be thrown somewhere.

There are enterprise B2B niches where a single small shop can service hundreds of clients, without needing uber-scale (see: you will never exceed 1mil concurrent users).

You can run everything on a single bare metal server if your dev team knows how to not waste resources (see: no ORM/toy databases, sane/strong-typed and compiled back-end language, use a mature package environment and tools, etc.).

Give a decade, and you can then cash-out when a bigger enterprise B2B shop buys you out. It's not an adderall-fueled manic-depressive roller coaster of a time; but it's honest work.

Best part: the only problem I've ever hit with scaling was people being stupid with their databases.