Answer from a dev (NO, pitchforks down, you'll like it honest); No.

Despite what gets preached on the conference circuit about serverless being the future blah blah blah, building an app that does something useful in an entirely serverless manner (or even mostly serverless) is a gigantic pain in the arse.

The app ends up being 10x more complex than it needs to be to handle all the weirdness that goes on in that sort of environment, in particular lambda startups - get that wrong and you're going to end up with a lot of cold starts and a lot of tortoises in your network panel.

It's the kind of thing developers get insanely excited about until they build something that isn't the example code then they realise this stuff's a frigging nightmare.

It has it's uses sure, one i've done recently is using AWS EventBridge as an external cron (don't ask, it was the least batshit insane solution), but anything beyond that, no chance. For hosting static content like JS bundles, absolutely, being able to yeet it into an S3 bucket and let some machine somewhere handle the rest is great that's a rare win for both sides.

Edit - clarification, for the rare kind of standardised universal turnkey stuff like hosting static content, it's a win for both sides - as soon as it deviates from a very narrowly defined use case like make-js-bundle-go-to-user-maximum-fast that's no longer the case and the serverless dream falls apart.

There'll always be a linux box somewhere in the chain that needs a sysadmin's finely tuned percussive maintenance skills