Choosing a Tech Stack for MVPs: A Pragmatic Approach

Picking a tech stack for an MVP gets way too much debate online. Most of the choices that look momentous have small actual impact. The thing that does matter — your team's speed in the chosen stack — gets too little attention.

Use what you know

Whatever stack you can build fast in is the right stack. If your team knows Laravel and Vue, build the MVP in Laravel and Vue. If you know Rails, use Rails. The marginal advantages of "the best modern stack" are dwarfed by the cost of learning while shipping.

Optimize for time-to-feedback

An MVP exists to put something in front of users so you can learn. Anything that delays that is a tax. Tech choices that get you to user feedback in two weeks beat ones that get you to a more elegant architecture in two months.

Don't pre-optimize for scale

An MVP that handles 100 users on a hobby Postgres instance is a fine MVP. Distributed databases, microservices, and Kubernetes are problems you do not have. If the MVP succeeds, you will rewrite parts of it anyway. If it does not, the elegant architecture was wasted.

Pick boring, proven options

Postgres, Redis, a mainstream framework. Avoid the hot new thing that has been out for six months — you will hit edge cases the community has not seen, and you will be alone with them at 2am. Boring tech is reliable, well-documented, and recoverable.

What to spend time on instead

Talk to users. Refine the value proposition. Build the actual product. The tech stack is a means; the product is the end. The number of MVPs that died because of stack choice is dwarfed by the number that died because nobody wanted them.