Live data from Hacker News

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

news.ycombinator.com

341–350 of 736 posts

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

#341
Currently building with Next/TRPC/Prisma/PG and would choose it again. I might be a little slower than starting with a full-featured MVC kit like Laravel or Rails, but having an e2e type system is so worth it to me. I do miss having a more mature ORM.

I'm constantly tempted by Phoenix but desuaded by the lack of a type system. Does elixir somehow make up for the lack of types as a functional language? Also, I can reuse a good deal from my current stack in a react-native app for mobile, which I'd miss out on in another framework.

Wish I could say Flutter, but have not been impressed by the web experience.

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

#343
post #97

I'm currently approaching MVP / ready to pitch stage on something and these are my choices- Rails 7.1 w/ Tailwind (esbuild, not import maps) Postgres DaisyUI for Tailwind UI components View Components for Ruby Nothing particularly "hot" but there are some newer tools Post MVP, the only thing I'm looking to change is potentially replace a very heavy data analytic background job with a Crystal version of it. Will be su…

Sounds great. Curious, what did you use for auth?

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

#344

Earlier quoted context omitted.

Eh.. you'd be surprised. Medical Imaging isn't as radical as you may think it is (I spent 7 years doing projects for the exploitation of medical images).

I’ve had the pleasure of annual echo cardiograms my whole life, and moved around a lot, and at least my experience has been visible hardware/software/imagine improvements almost annually. In any event I wasn’t saying all medical imaging is state of the art, I was saying it is another field where people prefer newer tech.

Absolutely fair. The vendors have gotten much much better tech "in the room" as it were - CT's are lightning fast anymore, US is clearer and can do more on-the-fly analysis than ever before (e.g. highlighting bloodflow dynamically and capturing tons of data in microseconds), etc. Every modality has grown tremendously so my comment wasn't nearly fair enough in acknowledging that.

Downstream is getting better with items such as AI advancements and more sophisticated mechanisms to transfer data between systems both on-prem and cloud-based, however utilization of all of this tend to be stifled a ton by the standard issue of tech moving faster than policy. My frustration/disgruntlement is due to this issue more than anything.

Thanks for the insight and the reminder that my bubble of experience isn't the world - seriously.

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

#345
I wish i could use Go, but we are not there yet framework-wise, so I'm either using Phoenix or Rails, depending for the team.

If the code is planned to be a separate React + API app, for example because React Native will be used, the I'd use Go

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

#346

I know this is not really in the spirit of the question, as asked. But an important consideration after having spent countless hours over many years building “MVPs” that ultimately go nowhere. Hire a PHP/LAMP dev for $10/hour or less (or whatever is cheap and good enough) + something like digital ocean. Communicate effectively the features and milestones and project manage but mainly Spend my time on growth I’m at a…

I've done this a bunch

It rarely works for me

Prob a bunch of reasons but

  - low dev expertise 
  - dev burnout bc it's prob a one man shop 
  - overengineered too aggressive on my part -- ie too complicated for an MVP

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

#347

Earlier quoted context omitted.

Would that be in Rust for performance reasons? Elixir IME isn't as slow as some other popular languages but it's no speed demon either.

A crawler should be limited by the network not CPU. Outside of the language making it easier to handle multiple concurrent connections, I doubt speed would be much of a consideration.

I'm not sure, it might be. If you're not careful, CPU can become bottleneck when you have a 10Gbit network card.

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

#349
I'd likely go for a mobile first approach and start with:

create-universal-app : https://github.com/chen-rn/CUA

Which would give me: - Tamagui - React Native Web Lite - Expo - Next - Solito - Prisma – Clerk - tRPC

But I'd likely throw out Clerk for a cheaper option:

- Supertokens, since it's also easy (lots of enthusiastic reports about it), has a managed solution (which is cheaper than the alternatives), is secure and scalable (rotating refresh tokens with JWTs), open source, offers passwordless / magic links, and the architecture of Supertokens would allow me to simply and quickly eject to self-hosting it if/when I'd eventually need to (if the app ever reaches mass-market scale).

And I might throw out tRPC for the equivalent GraphQL and TypeScript inference experience (esp. if business strategy dictates I need a 3rd party API):

- GQty.dev on the client, for inferred queries/mutations. For rapid dev speed. Simple code example: https://gqty.dev/docs/intro Then move to URQL or Relay at scale, or just skip GQty and go with URQL from the start (if scalability trumps dev speed).

- Pothos http://pothos-graphql.dev on the server, for auto building the schema from your TS code (aka. code-first). Better than Nexus (e.g. Max Stoiber moved from Nexus to Pothos on his Bedrock starter template because Pothos is best in class: https://bedrock.mxstbr.com/tools/pothos/ ).

And I might throw out NextJS (Webpack) for the equivalent experience in Vite:

- vite-plugin-ssr, since both architectural control (libraries > frameworks) and Vite rocks. I'd likely then have to make solito-vite https://github.com/nandorojo/solito/discussions/157 to have a unified navigation between React Native and Web, but Solito is allegely tiny, so recreating it should be doable.

(If doing all of these replacements, maybe starting from scratch would be easier than modifying create-universal-app ... That said, I think if someone made a starter repo with the above choices it would be a real killer!)

Then I'd also likely use:

- Vercel (and try their Edge Functions, for a serverless sweet v8 isolates experience without slow cold starts), or maybe Cloudflare Workers (cheaper, slightly more hassle?) for hosting.

- Planetscale or Supabase for the DB. (Not brave enough to try EdgeDB or SurrealDB just yet, though EdgeDB is close..) Unless I had a specific use case where a more specialized/optimized DB would make sense.

This stack should stick even post-MVP, as it's not only optimized for a solo developer but for scalability.

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

#350
post #208

.NET 7 & SQLite. Because I wouldn't need anything else. Also, it could potentially be my final stack depending on the size of my business & market. The current Kestrel web server implementation is extraordinarily fast (i.e. millions of requests per second fast). Vertical scaling isn't exactly a problem now that we have 2S servers with 256 cores (and beyond).

Have you found any good managed places to deploy modern .NET apps other than Azure? My experience is you can either use Azure, in which it's fairly abstracted for you but overpriced, or you can use something like DO where it's more reasonably priced but you have to handle everything yourself.

Just for clarity for others passing through this thread ...

Current .NET produces stand-alone cross-platform executables just like many other stacks.

Unless you're forced to do legacy stuff, there is no Framework any more, and no Windows or IIS needed. They build and deploy exactly like other ecosystem executables because that's exactly what they are. You can even generate a Linux server build from Windows and MacOS. And it also works fine with standard container stuff.

By default a .NET web app or API is a stand-alone server, with optional https built in, and you can either sit it behind a proxy like nginx or you can direct traffic straight at it. In summary, forget all the old stuff about frameworks, Windows, and IIS. If you're doing your own project and not working legacy stuff you don't need any of it.

Post reply on HN