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

[nvln]

Specifically the backend. I'd love to hear your reasons. Do you keep one eye on what the stack would be post MVP?

1. Old schoolish (VPS - Maybe DO, Django/Flask/Rails/Remix/Next with postgres)

2. Supabase etc with JS/TS on either side of the network

3. Lambda/Cloud functions with Firebase/Dyanamo DB/Cosmos DB etc

4..n. What else and why?

[nyxcharon]

After working with the PETAL (Phoenix, Elixir, TailwindCSS, Alpine.Js, Liveview) stack at $JOB for a while now, I have to say I've never been more productive.

Early on I would still have to lean on Alpine heavily for various JS interactions but with all the features Liveview has been adding and improving on (Hello JS module!) I find myself needing it less and less. Liveview really has been a game changer for me. Tailwind has more or less fixed most of my frustrations with CSS and has worked itself nicely into the company design system resulting in nice re-usable components that can be easily customized for those one-offs. Elixir is a nice language to use and I find myself missing features of it when working with other languages. Phoenix is well structured for projects and the newer generators solve a lot of common issues/features in projects like user auth in a reasonable way.

Depending on the needs of the app I'd look into deploying to Fly.io otherwise I've been using Kubernetes with little issue. I've toyed with Nomad for orchestration but haven't used it enough to give an opinion. I do wander if it's a nice middle ground for those who don't need the full suite of what K8s offers.

[davehcker]

I second this. I would say that I am pretty advanced with Python (and Django) and same with JavaScript (Vue and Nuxt) and have written applications that got used by multiple users. I saw a sharp rise in my productivity when I knew enough about the frameworks. But Elixir + PhoenixLiveView + Tailwind has been life changing.

I learned Elixir for the sake of the joy of learning a new programming language and I kept playing with it for few random days over 5-6 months. Finally, I took the leap of faith and for our startup I started the switch to Elixir + LiveView with minimal JavaScript hooks and I feel a weird bliss that we are two engineer FTEs and I can add features on a daily basis. Why that's the case, I still haven't ruminated myself, but my guess is 1. I have gotten older, 2. Elixir is beautiful and productive by design-- pattern matching, everything is a process (so the dimensionality of time is not an issue at all) and the code is kind of a right balance of simplicity and complexity, and in my opinionated view, there is "one" right way of doing things. 3. Standard tooling (mix, ExUnit). They have enabled us to write really maintainable code and for our next hires, we are willing to pay for them to learn Elixir than switching to other languages. Of course this is only for true for our web app which is actually a weird beast that interfaces farms, sensors, algorithms, and humans.

[scwoodal]

I also would choose Elixir/Phoenix. Having spent my career in Python/Django, Elixir/Phoenix/Live View is on another level of productivity.

For anyone needing a reason to jump into Elixir, take 40 minutes and watch this talk [1] by Sasa Juric. He communicates things so well as to all the benefits of Elixir/Erlang/BEAM.

Then take the time to read Elixir in Action book (again, Sasa) and you'll be off to the races.

[1] https://www.youtube.com/watch?v=JvBT4XBdoUE

[rozap]

I also went this route, but am keeping the infrastructure simple in order to minimize lock in. It has been super productive but also I've spent years using elixir professionally and unprofessionally so I'm comfortable with it. The nice thing is that the elixir ecosystem is so robust you don't need to get locked into whatever cloud provider solution is in vogue at the moment. Also, we got a pile of cloud credits from different providers, and intend to use them :)

[innocentoldguy]

I too would reach for the PETAL stack you mentioned. I don't code professionally anymore, but when I did I had experience using a lot of different languages (e.g., C#, Java, PHP, Ruby, Elm, Python, Perl, Lisp, Node, Clojure, F#, etc.). Elixir is by far the most productive and joyful language I've ever experienced. It's absolutely beautiful.

[afhammad]

Adding my vote here. Throughout my career I've gone the C#.NET -> RoR -> Clojure -> Elixir/Phoenix route. After spending a year with Elixir, iterating rapidly on a production system, I'd default to it for any MVP or serious project going forward.

LiveView is also very close to becoming default over React for interactive Frontends.

[Haegin]

We use Nomad at $JOB and it's been great. We're a small startup with one senior site reliability engineer doing pretty much all the infra work and I (~CTO) chip in when I can be useful, though when we adopted Nomad it was just me working on infra.

I looked into Kubernetes (I haven't worked with it at all before) and there just seemed so much complexity to handle things I didn't need that it was too much to learn for the benefit. Once I found Nomad it was a lot simpler, but it has everything we need and that's stayed true as we've grown.

I'd definitely strongly recommend it if you're wanting an orchestration system and don't need the complexity Kubernetes brings.

[mxgrn]

For deployment I'm using Docker + Github CI + Digital Ocean basic droplets. Docker support is built into Phoenix, all you need is `mix phx.gen.release --docker`.

What I like about it is that upgrading a DO host is basically a matter of spinning off a new droplet and install Docker on it. Also, setting up deployment for a new Phoenix project takes about 30 minutes now.

[bratsche]

I feel similarly, except for the AlpineJS part. I think PETL is fantastic and I would 100% choose that for my stack.

[Abishek_Muthian]

Is Liveview CSP compatible? I found out that Alpine isn't and the alternate CSP build of it isn't stable.

[arnonejoe]

I'll second this. Alpine.js is so nice.

[gianpaj]

Fly.io is great!

[jrvarela56]

Personally big on Rails (use it at work every day). But, my last MVP I did with TS/Next/Mantine/Supabase/Vercel.

Reasons:

- I've been using Rails as an API only, so having to grok views felt like a waste. My React skills made me feel that learning how to make complex views in my backend was a waste of time.

- One type of bug I hate is ensuring my API calls have the right schema. With Supabase and TS in the frontend, this is a non-issue: export types from db schema and all frontend requests are typed.

- Supabase is something for sure: I had been eyeing it for a while now, and it did not disappoint. Getting endpoints - even with realtime updates/subs in the frontend - after just defining a schema is magical.

- Auth is super simple with RLS - all this uses my SQL knowledge and makes me double down on it, which seems like a sane choice given it's been around for decades.

- Mantine gives me a large list of prebuilt components. This isn't exclusive to this stack but would highly recommend using something like this instead of just Bootstrap or Tailwind on its own.

Overall I'm happy with the results, feels way faster than my React/Rails workflow. Way less time in the backend (models, migrations, presenters, etc), more focus on tweaking the product.

Con: does not move me in the direction of using Python more. Feel like this is going to be a must-have for AI-powered components.

[bottlepalm]

Same, Next.js, Vercel, Prisma, Supabase. I push to my GitHub repo and the site is live and deployed in less than a minute.

With the stack you can use the same language, DTOs, libraries, etc.. both server and client side.

Server side rendering ensures a graceful handoff between server rendered state and the resulting app state on the client.

I’m also using MUI which includes all the components you need for a front end app.

I also just really like react/JSX, very strongly typed coupling between the html and JavaScript. Makes it very easy to refactor and pull out new components with confidence.

I really think this is the best stack for an MVP CRUD app right now. Interested to hear of anything better.

[michaelteter]

> Con: does not move me in the direction of using Python more. Feel like this is going to be a must-have for AI-powered components.

This is why too many companies build on Python... some thought that maybe someday they will need some AI something, and they hamstring themselves from the start with inferior tooling.

[foxandmouse]

I'm glad I came across your comment, I'm planning a 2-week project for learning purposes and I thought rails backend with react/ svelte would be the fastest way to prototype.

My ruby/ rails experience is very limited compared to my JS experience; I really just started experimenting with rails. I'm blown away by the magic, JS frameworks feel like toys in comparison. I also like that Rails is omakase.

Based on your experience, would you suggest trying rails or going the full JS stack route?

[halfmatthalfcat]

Mantine is such a good library, especially when compared to Material, Semantic, etc. I’ve used it with a couple projects and have been very impressed.

[ultrasounder]

Definitely old schools. I am building a MVP right now(kinda building my parachute while jumping off the plane)and I went with Django. And here is why. 1. Very vibrant community of devs and time-tested open-source libraries.If you want a multi-tenancy there is a library for that. IF you want stripe integration there is one for that. If you want "fully built out" services, then we have a plethora of free and paid templates. There are folks here(HN User rlawson)who have built many side projects using Django that they have monitized. if that monetization is your goal, then time is money and Django is your friend. 2. Very easy to deploy. This is a Major major requirement for someone like me(dabbling in webdev). Even after the demise of Heroku hobby dynos, there are things like Railway.app which lets you git deploy app, try it out and then scale it if you want. 3. Lastly, Javascript not necessary- I am a "hobby python dev". I don't have the inclination nor the time to learn yet another Javascript framework. I have an idea, know a bit of Python and I want to iterate it on my idea fast and get to the customer ASAP. Meaning, I can deploy a MVP without having to dabble with JS while jumping through all the different web pack configurations. A big win for me. So, "boring stack" definitely.

[physicsguy]

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 you should be worrying that much about how to store users in the database and add RBAC and building a way to add middleware and a storage layer and all of that crap. It’s not worth it, your application is not a special snowflake.

Edit: Should say that with that I mean serving HTML via Django. Usually I would use Bootstrap for layout. Very occasionally I’d add an API for some interactivity but I think for most MVPs interactivity is likely to be a secondary concern until later.

[skizm]

HTML, css, js, (maybe jquery and font-awesome if I want to get fancy) and all static files dumped in an S3 bucket for as long as I can get away with it, then django if I need anything more. Not that I think python/django is the "best", but it is what I know and it's got all the batteries included out of the box. I've never made a sufficiently advanced UI that required react/vue/etc. So I still just stick with html/css/jquery on the front end.

Semi-related side note: I do use TS/react in my 9-5, but the more I use it professionally, the more I'm convinced there is no need for it outside of trying to get a job, IMO.

[v3ss0n]

Hhere is quick survey :

Regarding backend choices:

  curl "https://news.ycombinator.com/item?id=34530052" | grep -i Django | wc -l
  36

  curl "https://news.ycombinator.com/item?id=34530052" | grep -i supabase | wc -l
  17

  curl "https://news.ycombinator.com/item?id=34530052" | grep -i rails | wc -l
  28

  curl "https://news.ycombinator.com/item?id=34530052" | grep -i node | wc -l
  15

  curl "https://news.ycombinator.com/item?id=34530052" | grep -i elixir| wc -l
  14

  curl "https://news.ycombinator.com/item?id=34530052" | grep -i phoenix | wc -l
  7

  curl "https://news.ycombinator.com/item?id=34530052" | grep -i fastapi | wc -l
  7

For Frontend Choices :

  curl "https://news.ycombinator.com/item?id=34530052" | grep -i svelte | wc -l
  9
  curl "https://news.ycombinator.com/item?id=34530052" | grep -i React | wc -l
  34
  curl "https://news.ycombinator.com/item?id=34530052" | grep -i htmx | wc -l
  15

[LeonenTheDK]

Well that depends a bit on what the MVP needs to be.

Anything web related I'm probably going the Elixir/Phoenix route. I'm no web dev, but this combination makes me actually kind of like doing web-things with how batteries included it is, and the tools it provides to really jump start a project. Then I'd host it "old schoolish" in a VPS or similar since that's what I know best. Might consider being fancy and investigating if Fly is a good fit. If a DB is required I'd use SQLite unless some constraint pushes me into Postgres.

If we're talking command line tool, the correct answer for me would be C# since that's what I know best. The answer I'd want to give though is Go since I want to get deeper into it, but that's not a good business decision.

Desktop application, best I've got in my kit is WinForms with C# and prayers that it never need run on anything but Windows. Maybe Linux with some Wine trickery, but that's not something I've done before either.

[mrdoops]

Agreed Elixir/Phoenix + Tailwind is at the sweet spot of scalability, performance, and bonkers productivity.

Real time? Need to go distributed? Maximize # of features / developer bandwidth? Cutting edge machine learning training & model serving?

Mobile? JSON APIs and GraphQL tooling is great, but https://github.com/liveviewnative is moving fast so this stack almost has the exodia of full stack, one language, and distributed actor model based scalability.

[nelsonic]

Totally agree! For almost all web-based MVPs the PETAL Stack (Phoenix with LiveView & TailwindCSS) deployed to FREE Fly.io is an epic choice for both response times, realtime features, dev speed (time to market). We're currently building our MVP with it and it's fully Open Source so anyone can learn from our journey: https://github.com/dwyl/mvp

[el_nahual]

LiveView is great but IMHO it's easily abused. "No JS, ever" is a mistake. IMHO it works best when there's very clear rules with where one should use LiveView vs JS.

[sph]

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.

[jstx1]

If the backend, frontend, API and data layer are in Elixir, what's actually written in Rust?

[0x008]

But do you code in vim?

[newaccount2021]

I love Rust and program in it a lot...but I would never use it for an MVP

Rust is the tool you use when you are done prototyping, not when you are just beginning

[apocalyptic0n3]

For an MVP, I'd choose what I'm most familiar with and can be fastest with. That would mean:

1. Laravel

2. An Ubuntu VPS in either Digital Ocean or Linode

3. A managed database in one of those services, likely Postgres

That would get me to market the quickest. I have no issues with the application being in Laravel/PHP and after getting to market, I'd work on making the infrastructure scalable. I wouldn't expect overnight success, so a single VPS and managed database would let me keep costs low while I pick up a few customers and then work to handle the scalability in the background (likely AWS with a combination of EC2/ECS/Fargate, RDS, SQS, SES, CodeDeploy, ElastiCache, etc.)

[mooreds]

> For an MVP, I'd choose what I'm most familiar with and can be fastest with.

That is absolutely the takeaway here. Use the technology you are familiar with and/or can be fastest with. MVPs are risky enough, don't add in "oh, gosh, I have to learn the tech (libraries, deployments, monitoring, database access, etc)" as well.

The only case where I'd pick a new tech for an MVP is when there is an existing open source or free project that I could use that would obviously get the project shipped faster by providing extensive pre-built functionality.

For example, I once used Sharetribe https://github.com/sharetribe/sharetribe even though I was only an intermediate ruby programmer because, after time spent evaluating it and other solutions, it had functionality that could get us shipped faster.

From "git init" to our first beta customer was 1 month of time. Then to our first paying customer was 1 more month. One developer (me). To be fair, my co-founder had done a ton of market development before I started coding, so the initial market/feature discovery was done; that's a huge part of any MVP.

[sanjayio]

Why opt for managed db?

[adrianthedev]

Nothing really beats Rails. Use something like Jumpstart (jumpstartrails.com) and Avo (https://avohq.io) and you scaffold a full consumer-ready app in literally a few hours.

The thing that bugs me the most with Next.JS and the whole JAMStack movement is that, yeah, you get from "git clone" to deployed on Vercel in two minutes, but if you need to create real app features like a sturdy admin, accounts, authorization, proper asset management, CI/CD, it takes a whole lotta time. I'm not even touching the most common app features. I'm speaking from experience, from building a Next.JS app for about a year.

Most Next apps out there are incomplete with the worst freaking user experience. Insert any other JS framework or hosting provider in the place of Next.JS and Vercel.

Of course, this is a generalisation, not all Next apps are that bad.

Using Rails is like a cheat-code in dev term.

[justsomeuser]

- Server: Node.js + SQLite

I know JS very well, so writing HTTP handlers is quite fast.

Node runs on V8, which is probably the fastest runtime for dynamic code.

SQLite makes development easier as it’s just a file, gives you ACID.

- Frontend: React/Mobx/Tailwind SPA hosted on firebase hosting.

I think the concept of JSX (write your HTML with JS) is good as it gives you a real language instead of a restricted templating DSL.

Tailwind for the fast iteration speed.

Firebase hosting for the simple CLI and fast CDN.

- OS and hosting: Docker running on Google Container Linux

Docker so that the OS level dependencies of my server are defined somewhere.

Container Linux as it auto updates and has all the GCP logging and monitoring built in.

GCP for the incremental disk snapshots for simple backup of the SQLite state.

If I had to scale the service I would add more CPU cores and faster disk. I would also move the parts that need scaling to Go/Rust, and design the code to make use of the cores.

A few principles I use when choosing tech:

- Avoid distributed state (network boundaries) when possible (SQLite instead of SQL server, function calls instead of micro services).

- Use tools for their primary purpose. No shoehorning. Issues arise when you try to use something for what it was not designed exactly for. If you have >3 tools in your stack that you are shoehorning, things are more likely to break in the future.

- Things should still work in 10 years with minimal updates. Lindy effect. Bet on older tools if possible as they are more likely to be around and maintained.

- Good enough vs optimal: stop trying to find the perfect tech. Web tech is sometimes messy and imperfect. Opinion over what is right changes.

[logifail]

> What would be your stack if you are building an MVP today?

Many years ago a CIO told me he didn't really care what technologies I picked for an upcoming MVP backend, as long as I was already comfortable with them and would therefore be productive quickly.

He also told me we would almost certainly need to rewrite everything at least once, so not to dwell too long on the initial stuff.

Build the MVP, build it quickly, get it in front of users. It just needs to work, you're not going to get marks, or customers, for backend coding style.

[thecodemonkey]

I would pick whichever stack that I would be most productive in.

A Laravel app hosted with Laravel Vapor (AWS Lambda) with a MariaDB database. Would allow me to get up and running quickly, at low cost and without having to worry about scaling for a long time.

Using Tailwind and VueJS or AlpineJS for the frontend.

[verisimilidude]

It really depends upon the product, right?

Let's assume we're talking about a web-based business app.

If the MVP already requires some complex business logic, then I'd probably choose an old-school stack. I personally prefer Rails. But I'd probably pick .NET. Above all, my metro area is full of .NET people. It'd be much easier to find/hire collaborators in .NET. I'm comfortable and productive enough with .NET on the technical level.

However! If I could get away with just putting up a couple Lambda functions, then that's absolutely the path I'd choose. It's an MVP. Let's get this boat rowing ASAP!

In short, product and market influence the best technical approach.

[andyjones11]

Elixir, Phoenix, LiveView + Postgres

Main reasons are:

- Can build entire app (with SPA-type experience on the FE) in a single codebase

- No need to build any HTTP APIs

- Periodic tasks and managing in-memory state is super easy in Elixir. Eventually you might want to stick state somewhere which survives restarts (eg redis) but for the sake of moving quickly Elixir makes this really easy

- Newer versions of Phoenix/LiveView support html components so building out UIs now feels as nice as some of the tools in the FE ecosystem

[kcartlidge]

I like Phoenix/LiveView so it's a nice option.

But I'd probably choose Blazor over it as every one of those bullet points also apply to it, it's C# (with which I'm very familiar), and if it takes off there are masses of devs available in most markets as opposed to handfuls currently for Elixir/Phoenix.

Coupled with something like DO droplets and SQLite/Postgres.

[danieka]

Depending on your use case you could consider using SQLite. For example storing auth info in a central database and then having one database per customer.

[aantix]

I built Call Stacking ( https://callstacking.com/ ), a modern Ruby on Rails debugger, with Jumpstart Pro and 1.5 hours a night over the course of 4 months.

We have four kids, host an exchange student, a new puppy. Our schedules are full.

Nothing compares to the productivity of Ruby on Rails. Especially when coupled with a high-end template like Jumpstart Pro ( https://jumpstartrails.com/ ).

[mooreds]

I used something similar ( https://bullettrain.co/ ) in the past. Have you taken a look at that? Bullet train used to charge but now are apparently open source.

[adrianthedev]

Next time check out Avo. It integrates perfectly with Jumpstart (or any Rails app) and helps you create a back-office app in no-time.

https://avohq.io

[roflyear]

When I click examples why don't I see code?

[sourdesi]

I’ve been working on a side project that aims to provide a really simple UX to spin up full-stack web apps with CI and scalable infra by default. The idea is that you would simply enter a domain name you want to purchase and then the tool would do the following:

1. Purchase the domain name using AWS Route53 (perhaps you’d need to setup an IAM role for the website to access your pre existing AWS acct)

2. Setup frontend, API, and CDK infra repos. All in TypeScript.

3. Frontend react, backend Api gateway backed by lambda functions. Have a graphql endpoint that talks to an Amazon auroradb. CI for backend and frontend is defined by a CDK package that is also deployed to the AWS account that also sets up the networking and database for you.

4. Have a basic layer of application code for setting up user authentication and storing user data in the aurora db.

Basically my idea is it kinda sucks that everyone has to do all of this setup yourself if you want to start a new project. Or you have to rely on no-code tools like Squarespace etc which may not be what most engineers are looking for. Having something that can go from simply entering the domain name you want to scaffolding out a fully functional full stack web app with CI and serverless infra defined by code that can scale from day 1 seems both incredibly useful and doable.

Curious to hear other people’s thoughts on this!

[noodle]

Rails on postgres with React in the frontend is my default swiss army knife. I know Rails well and it still gets stuff done fast, comparatively speaking. If the problem space I work in requires something different or solves the problem better than Rails, I'd switch.

Edit: post-mvp, I'd stick with Rails still unless there are specific difficulties with it. But I've yet to have major issues building a large Rails team/project, including present day.

[gls2ro]

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

[bob1029]

.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).

[pc86]

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.