Ask HN: What would be your stack if you are building an MVP today?

I'm surprised "Next with Postgres" is under "Old School" here.

Building an MVP to me means you are building a Proof of Concept (POC) for investors to see the value in your product. Using something that has a proven and lengthy track record and plethora of industry resources in the market feels like the right approach.

Depends on resources too... If you have separate resources for FE and BE. Probably still go Rails for BE. The upsides to Rails is productivity and job market. I'd track metrics that would help you keep an eye on application performance where it matters and iterate on those areas post-MVP.

For the FE I'd go NextJS... You can use it as just React or actually use all of the pieces to it where necessary. You can host it on a server or toss it on Vercel or Netlify to have less worries until you outgrow those (if ever).

For the database I'd probably use something that works well with Prisma JS for productivity, PostgreSQL or MySQL.

I'd stick to TypeScript for that productivity too. The iteration speed is a brain dead reason to use it.

If you can make the BE and FE with the same team and use all TypeScript... I'd use NextJS + Prisma JS + tRPC. tRPC would give a huge productivity boost because of its TS integration into your project. You just need someone senior enough to establish guard rails like the boilerplate, linter, and other guard rails to keep more junior developers on track and productive.

I feel that the combination of these frameworks will give you the right mix of quality and iteration speed without sacrificing one or the other. Also, great hire-ability. Though, all of this depends on if you actually need a DB and a backend, or even a frontend for what could suffice as an MVP.

Just some thoughts...

No additional framework, just a typed language with good standard library and raw SQL. For the frontend I would probably reach to HTMX.

In my experience, I'm far more likely to run into database bottlenecks early on than web server bottlenecks (largely through hastily and poorly written queries or unchecked Eloquent N+1 problems). I'd opt for the managed DB so that there's limited chance that the database will affect other processes on the webserver (including serving requests, handling background and scheduled jobs, etc.)

It also makes it easier to scale within Linode/Digital Ocean if you find yourself needing to do that before the more complicated AWS infrastructure is ready.

Figma

I wonder how well mud Blazor works in a MAUI Blazor app when it's all packaged locally and compiled to native.