I may be an outlier here. But I strongly prefer not to optimize for speed when building an MVP. Because it just _never_ (at least in my experience) gets a chanc

I may be an outlier here. But I strongly prefer not to optimize for speed when building an MVP. Because it just _never_ (at least in my experience) gets a chance to be fully rewritten into something better. The idea of an MVP is to prove the market need and if it’s proven, the wheels are already turning and it’s impossible to resist the pull. So you end up with a bunch of tech debt or just inefficient stack that poisons your codebase from day 1. I think the initial gain is just not worth it in the grand scheme of things. So we always are trying to use the best possible production stack. Not overengineer - just use the best solution for the long run. Long term gains beat marginal short term benefits. Currently our stack for a pretty small eng team is Go, React, GQL and Flutter for mobile. Works pretty well for us. But as I said, I could be an outlier here :)