The preferred stack will be Django with DRF and maybe some htmx, SQLite and deployed on DO app platform.
Alternatively, NextJS with Firebase (or any other cloud DB) and deployed at Vercel.
Ask HN: What would be your stack if you are building an MVP today?
491–500 of 736 posts
Re: Ask HN: What would be your stack if you are building an MVP today?
#492Earlier quoted context omitted.
IMHO, part of this is that people have accepted the poor experience of non-realtime applications. But there's a huge UX improvement if the application responds faster than users can input actions. Doesn't matter for all applications but if your users are going to spend significant time inputting data it makes a huge difference. Also IMHO, a flexible type system like Typescript makes development faster than without it…
>If there's any chance that the application will grow beyond a few developers I think it hurts more than it helps. Simply not true. I've consulted on multiple teams across products built with Rails. Products that supported hundreds of millions of requests and generated a similar levels of revenue. Rails scales - programmer productivity, traffic. It scales.
One thing I've taken to pointing out, and it seems like you have way more experience with which to back it up - is that it's not just about scaling to millions, it's also about scaling from zero.
Thoughts? :)
Re: Ask HN: What would be your stack if you are building an MVP today?
#493After 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. Tail…
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.
Re: Ask HN: What would be your stack if you are building an MVP today?
#494Go & Postgres on the backend, running on a baremetal server. Because this is actually capable of handling a decent workload for really cheap compared to cloud. There's a few tricky bits to do with logs and reporting, but the benefits outweigh the pain. Vue on the frontend. Last time I used BootstrapVue and it worked well. I'd want to re-evaluate that decision next time, have a look at some of the newcomers. I'm aware…
This is the correct answer. It's quite shocking how many Django and Laravel answers there are in this thread. Performance and type safety appear to be completely irrelevant to HN. You should take a look at Vite ( https://vitejs.dev/ ) for a Vue development environment, if you haven't already.
No, it’s not, because we’re talking about an mvp and not about building an ultra high performance micro service.
And btw, there is no “correct answer” despite how much you like it.
There are many “correct answers” and a lot more wrong ones. Like using assembly code for building a CLI app or Go for an MVP.
Re: Ask HN: What would be your stack if you are building an MVP today?
#495Svelte and Pocketbase
Re: Ask HN: What would be your stack if you are building an MVP today?
#496So many good answers, and interesting to read the overall technology landscape. The technology debates can be endless, though. I think it's good to consider a few non-technical aspects as well for selecting your stack -
1. Is this stack popular among recent similar successful products?
2. What technology will make it easier to find relevant talent?
3. Does your stack allow for rapidly changing code along with a rapidly changing team? This is important, especially in the early stages of development.
4. Are you trying to do things the Google way? Facebook might never exist had they started with C++ instead of PHP.
5. Do you want to be on the cutting edge for the sake of being on the cutting edge?
I elaborated on this a bit in my blog here if interested - https://sleeksky.com/blog/technology-stack
Re: Ask HN: What would be your stack if you are building an MVP today?
#497Earlier quoted context omitted.
For an MVP, none of those things matter. Just rewrite it in a different stack later if you realize that the one you picked doesn't fit your requirements long-term. Worrying about that stuff before you have users/customers is just a waste of time and energy.
But does that really happen? It seems that we have a lot of bloated, buggy, inefficient code out there because it was initially built using something that was 'quick and dirty' for the MVP and was never rewritten properly once it caught on. I have clients that still use Excel spreadsheets for their database instead of using a real one just because their data was initially stored there and they never changed. New feat…
Yeah, it's definitely a cultural shift from the way most software is built today, but it's a better way to do it in most cases. I was also assuming a startup environment in my comment; established companies can generally afford to do more work up front to make the foundation more robust, and they are (slightly) more likely to have a better idea of what their customers want ahead of time.
But to answer your question more directly, it does happen, it's just uncommon. Where I've seen it done successfully, the rewrites have been piecemeal, not all at once, so that definitely helps with the buy-in factor.
Re: Ask HN: What would be your stack if you are building an MVP today?
#4985. JakartaEE for the backend, Jakarta Faces + Primefaces for the front end, redis for the db, Javalin if API endpoints must be provided. Hetzner server. Only pain point would be the NGINX config, always non trivial.
Why? Very simple, fully featured, ready to scale.
Re: Ask HN: What would be your stack if you are building an MVP today?
#499I'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. Provisi…
But do you code in vim?
Re: Ask HN: What would be your stack if you are building an MVP today?
#500Personally 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,…
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 exp…
I'd stick with rails unless you have a complex front-end where UI responsiveness is of the essential (i.e., highly graphical-interactive). React is many levels up in terms of complexity.