Founders often ask us which framework or language is "best." The honest answer is that for an MVP, the best stack is the one your team can build and change quickly, not the one with the most impressive architecture diagram.
We weigh three things early: how fast we can validate the riskiest assumption in the product, how easy it will be to onboard a second engineer later, and how much of the stack is "boring" — proven, well-documented, and unlikely to become a maintenance burden.
That usually points toward a small number of well-supported frameworks rather than the newest tool on the market. Novelty can wait until the product has found its users.
Once the MVP proves the idea, we revisit the stack with real usage data in hand — which is a much better time to make architecture decisions than before a single user has touched the product.