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

The “only good answer” if there is just the one is that you should use whatever fits the requirements. If those requirements involve you getting to market as fast as possible in a highly generic domain (ie building a standard website) where the tools you know work just as well as others and you’re not worried about various other factors then sure, go with what you know and can churn out the fastest.

But though many projects may fit this mold they are by no means universal requirements, and your requirements may very well dictate the best path is for you learn new tech (for instance if you usually do .NET stuff but are building a a ML service on a device or something). Sometimes there are better ways to accomplish things than what you already know and you’ll indeed be better served by learning them. If you’re just a hammer looking at everything as a nail because you can bang on it the fastest you’ll stub your (and probably others’) thumbs one way or the other.

Not to mention learning new tech is often its own reward regardless of the much less certain fate of a given MVP. At the very least you'll have another tool in the toolkit to assess future project requirements, rather than blindly attacking everything w/ a hammer.

I love Django. It's criminally underrated.

Side project if anyone's interested in peeping it: https://www.fpgajobs.com

I was wondering about that actually.

Writing code in Python, Rails, etc is painful. A stupidly high percentage of the "unit tests" aren't testing logic at all, they're simply ensuring that incorrect types are handled properly.

And then I see comments like "well, my MVP can run very cheaply, a $100/m DO droplet" and wonder what on earth they are talking about - I had a $5/m DO droplet handling around 50k-60k concurrent TCP (not HTTP) connections, all serving data without any of the connecting devices timing out.

The devspeed differential between things like C#/Java/Go and Python/PHP/Ruby is large only at the very beginning of your project. When you're adding new features in every day, six months into the project, you're almost definitely going to be faster in some statically typed compiled language.

Seriously, using Django is likely to shave a week or so off the time; if that week matters so much then your expected lifetime for the product is what? Two weeks? Three?

I get it, in that if your MVP is timeboxed to (say) two weeks to alpha, then, yeah, those things that shave a week off make sense. But if your MVP is timeboxed to two weeks:

a) Tt's unlikely to be of much value to the consumer, b) Your competitors will appear two weeks after you first launch anyway.

I want to do a new product, and when judging each product idea I have, the largest issue is always finding the largest amount of value I can create/deliver in a particular timeframe (say, 3 months f/time).

If the value the product is providing can be done in a week with Rails, then there's not much motivation for me to develop that product - everyone with a week of leave or a month of weekends is going to have a clone out before I can even learn marketing.

If it's going to take 3 months regardless of the language, I have at least 3 months to build up a userbase, and do product refinement and fit.