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)

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.

I have a relatively terrible answer that I would recommend to no one but it works for me. That's the fastest stack for me.

The question wasn't "what is the fastest stack" or "of all stacks which is the fastest for you" but rather akin to "what is the fastest stack for you". Which is often the one that you are productive in.

It's almost always not worth learning a new stack to prototype something unless the goal is to learn the new stack.

you should check out https://wasp-lang.dev then. It's probably one of the fastest stacks out there for React + ExpressJS at the moment

That’s usually my take, but I still worry about a few things:

* which stack will still be around in 1/2/5years?

* which stack Will other teammates or future devs be productive in.

I’m still searching for a very light, productive open source stack that is well accepted and if not future proof at least we’ll backed.

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 features were added incrementally over time and it became costly to break everything for a complete rewrite. So they limp along forever because management won't let them do it right until it absolutely breaks.

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.