Live data from Hacker News

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

news.ycombinator.com

31–40 of 736 posts

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

#32
post #20

If it is a SaaS 100% Ruby on Rails Why: - has almost everything that I need usually in mature gems - battle tested in production - speed of development

I did so last year, and I cannot be happier. My only regret is that I wasn't aware of htmx/hotwire at the time. I went with Vue, and I regret it immensely.

Rails is the fastest development platform I've tried so far, it is predictable, well crafted, structured yet flexible. You can't go wrong with it.

Every now and then I try something new on a side project or I have to work on some other codebase for my customers, and nothing so far has tempted me to move out of rails for my serious projects

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

#33

Django, in my previous role we did MVP websites for academics and the speed of getting a site up and running and deployed was just so fast. I’ve never worked with anything else that is as fast, anything like FastAPI or Flask or Express or similar either requires additional libraries to add really basic and common functionality or you have to roll it yourself. I personally don’t think that if you’re building an MVP yo…

Nowadays, Django has an amazing library which is a lot like FastAPI but in the Django ecosystem. https://django-ninja.rest-framework.com/ It's absolutely wonderful. I would use that in a MVP, and do the F/E in NextJS + Typescript.

I’m familiar with it, and I don’t love DRF but the downside with Ninja is that you end up writing a lot more boilerplate IMO. Unless you’re strongly optimising for performance (and usually latency and the database are the biggest issues there), you can get away with ModelSerializer and DRF ViewSets a lot of the time for APIs and write very little code.

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

#36
I'm building an MVP solo.

Rust for the core application, Elixir for the backend, frontend, API, data layer. Javascript is pretty much non-existent, all client-side interactivity is done by LiveView.

Packaged into a podman container and deployed to a Hetzner dedicated server. Storage on PostgreSQL, probably the only thing I would rather not have to manage, but honestly single node is perfectly fine for an MVP. Provisioning is done with Terraform and Ansible.

Future expansion (pretty far away, post launch and post paying customers) is add more geo-distributed worker VPSes, talking to the central coordinator via Wireguard link.

Setup is pretty cheap, fast, scales really well, and it's easy to understand. With additional services (mail, monitoring, etc.) should be less than $100/mo all inclusive, and that should be enough for up to ~100 paying customers.

I have no plans of changing any part of this setup for the next decade. I'm too old to want to get golden handcuffed to turn key solutions and cloud products that just introduce complexity and become VERY expensive, and badly documented, past the demo stage.

Started in November, closed alpha release with users next month, launching Q2 2023.

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

#37

Directus connected to a Postgres database Comes with a built-in low-config UI/API for CRUD on the database, and easily extendable with Vue.js and Express endpoints. Additionally, should the need arise for something more custom later on, all your data is in Postgres rather than a backend as a service https://directus.io/

I've used it on a project a year ago and I've found it very effective for prototyping. But I eventually had to move out of it, and I don't see good you can make it work in the long run, as access management and data migrations are a PITA.

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

#39
FastAPI & Postgres for the backend. REST + websockets for the API. Over the years I've tried all kinds of BaaS and more magic "X as a service" solutions, but I often hit some edgecase or limitation that is a dead-end or run into some bug I can't fix myself. So I prefer the flexibility and robustness of Postrgres with the ecosystem of Python.
Post reply on HN