It's a lot more work than say Next.js and Vercel, but I suppose it costs a lot less to maintain in cash (trading cash for time).

I'm sure everyone's mileage will vary based on experience / comfort with the particular stack here... but in my experience shipping a monolith (Python, Ruby, whatever) to a VPS is vastly simpler than a comparable Next/Vercel setup, especially for a CRUD app as the OP is talking about.

Dealing with the details of things like SSR vs client side, Apollo caching (cuz w/ Next you are _probably gonna go w/ GQL, and so you probably use Apollo), and monitoring/observability in the Next/Vercel world is hard. You don't have these problems with a simple monolith, and you can sprinkle in your front end magic with whatever lean JS approach you want as you need it.

And to be fair Vercel has some logging and datadog integration, but it is very limited compared to what you can get and can configure as-needed with real agent based monitoring.

I'm increasingly feeling like the 'benefits' of server-side rendering in all its flavors for the big JS frameworks are just a boondoggle and not worth the complexity and cost for _most_ apps, even ones where the cost of an SPA are worth it.

- GQL: the only case where I'd use GQL is where he would likely want to too: building native mobile apps. Otherwise, I'd use tRPC and have fullstack type safety. This is included in my 5 minute estimate because I'd use create t3 app, which has this configured out of the box https://trpc.io/ https://github.com/t3-oss/create-t3-app

- monitoring/observability: not quite sure what you mean, but it's only a few clicks in vercel to have a logdrain or metric drain and configure alerts and dashboards in your tool of choice. And if I wanted to roll the whole thing myself... that's what he did. Rolled it all custom by hand. The difference is I have the option of not reinventing the wheel.

At the end of the day I can get into composing a docker image that is configured just like his prod servers if I need that access, and there's likely already a docker image pre-done that has 99% of what I need, including metrics/monitoring. At which point I could launch my service on any number of hosts that allow direct pushing of built docker images, if my build process goes there.

To each their own, but I think my solution requires far less time to setup and maintain, but costs more, as I said. Manually engineering each system yourself might be fun to you, but it's not to me.