The snarky answer is that it's easier to be a full stack developer if your stack starts and ends with JavaScript. It's also the real answer - most webapps create value in the instant of views or clicks, so being charged solely on those metrics (even 200%) can make a certain amount of business sense, and if your business doesn't have need for redundant data stores or major backend services, you can get a lot of mileage out of a vercel based infrastructure.
I personally can't stand it, and actively work to excise it from front-end applications though _because_ it's difficult to work with it as a 'part' of your world. Like a lot of dev-experiential products/business models, their moat only exists if they can keep you "in" vercel, the moment they become just nodejs + lambda to a customer, then their value-add ceases; So they make it difficult to "grow up" out of vercel -- for many shops that's fine, it will be all they need from it, so a premium for a polished nodejs+lambda+deployment+cdn experience is worth it.
But if you're a micro-arch with backend services running on your own cloud, vercel will always be the wart in your infrastructure making everything from network policy to authentication and monitoring or tracing more difficult.
I personally can't stand it, and actively work to excise it from front-end applications though _because_ it's difficult to work with it as a 'part' of your world. Like a lot of dev-experiential products/business models, their moat only exists if they can keep you "in" vercel, the moment they become just nodejs + lambda to a customer, then their value-add ceases; So they make it difficult to "grow up" out of vercel -- for many shops that's fine, it will be all they need from it, so a premium for a polished nodejs+lambda+deployment+cdn experience is worth it.
But if you're a micro-arch with backend services running on your own cloud, vercel will always be the wart in your infrastructure making everything from network policy to authentication and monitoring or tracing more difficult.