Live data from Hacker News

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

news.ycombinator.com

41–50 of 736 posts

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

#41

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.

This. Your fastest stack is not my fastest stack. If you want to learn the ‘fastest’ frameworks, that is a totally different decision than getting an MVP out the door. That is an educational one… which is totally valid just not in an MVP sense.

The goal of the MVP is ascertaining product market fit, everything else is waste. Use what you know and optimize later. If your MVP can handle 1m calls a second, you have failed (unless it was natively supported by the framework)

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

#42
post #9
post #5

Are you building the MVP to make a product or to learn a new technology? If the former, then the stack you are most comfortable with. Let the challenges come from the product-side. If the latter, then take your pick based on the reasoning for learning something new. Be it job-opportunities, curiosity, whatever.

I'm building the MVP to make a product and get some market feedback / validation.

Then build what you know… always the fastest choice.

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

#44

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.

This. Your fastest stack is not my fastest stack. If you want to learn the ‘fastest’ frameworks, that is a totally different decision than getting an MVP out the door. That is an educational one… which is totally valid just not in an MVP sense. The goal of the MVP is ascertaining product market fit, everything else is waste. Use what you know and optimize later. If your MVP can handle 1m calls a second, you have fail…

I think it's a very reductive view. One cannot try every stack to find its fastest stack. This is why people ask about other people's experiences. Someone might have a better solution, and a convincing argument, so you could try it and become more productive.

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

#45

elixir/phoenix is the best platform for knocking out an MVP today. Its batteries included and has a frontend system called liveview that lets you write most of your frontend using elixir too. You get built in pubsub and websockets which are important for any new kind of software product. Users demand more interactivity and phoenix lets you do it and scale from day 1. Ecto is easily the best sql database library I've…

I love elixir/phoenix and wish I could use them in prod for my job, but...

> pubsub and websockets which are important for any new kind of software product

... not really. By far most people (probably by a huge margin) are doing fine building 1000s of new products per week without either those things.

Further I think you are right.

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

#46
My sweet spot is

1.Flask with Postgres for API. 2. C++ with Pybind11 for core performance engine. 3.Whole stack running on a single cloud instance with docker compose. 4.Next.js, Typescript, Tailwind for frontend. 5.Github Actions for CI/CD and deployment to cloud.

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

#48
The stack on which I feel more comfortable right now:

TypeScript on both sides with fp-ts[1], effect-ts[2], Postgres or any random document database with low friction, a random view library that has the best support for jsx and both client/server side rendering (not react).

Any other stack would require me to learn new stuff and eventually slow me down.

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

#49
- 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.

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

#50
For a web-app of some sort?

Host: VPS on OVH

Database: Postgresql

Web layer (server-side): Grails

Web layer (client-side): Javascript - probably vanilla, maybe React. Bootstrap.

Auth / SSO: Apereo CAS

Deployment automation: Ansible

CI/CD - Jenkins

Issue tracking: Bugzilla

IDE: Eclipse

DNS: Route 53

If I felt the need for dedicated micro-services for the backend, I'd use Java and Spring Boot.

If needed, possibly Apache HTTPD as a reverse proxy.

For a lot of stuff that might fall under "other", like sending email, or text messaging, yadda yadda, I'd use Amazon services: SES, SNS, etc.

For an MVP I'm not sure if I'd even bother building Docker images or not. But if/when I had to scale up, then I'd definitely package as images and deploy using Docker or K8S. At some point if the thing got traction and needed to scale Big Time™ then I'd probably go to Amazon EKS or Azure AKS.

If I needed a mobile app... well, I'm not really a mobile developer, but I've been picking at learning Flutter. So probably would continue with that.

Post reply on HN