The question I get most from founders building their first thing is: what stack should I use? They want me to say Next.js, Rails, Django, Laravel, T3, Remix, SvelteKit, or this week's framework du jour. They want a definitive answer to stop deliberating and start building.
The answer is: whichever framework lets you ship by Friday.
Founders often want a technical answer that signals depth, but they get an operational one that seems like a non-answer. Here's why it's right.
Almost every framework choice for an MVP is reversible. Founders imagine the company at scale, where rewriting the platform from Rails to Go is a major undertaking. They aren't building at scale yet. They're building at zero customers, where rewriting from one stack to another is a weekend's work. The cost of being wrong about the stack at MVP time is roughly zero. The cost of being late, or never shipping, is enormous.
So the framework question becomes: which framework lets you, the founder, ship fastest? The answer is dictated by what you know.
If you've shipped Rails apps before, build the MVP in Rails. Don't switch to Next.js because the YC batch is on Next.js.
If you've shipped Django apps before, build it in Django. Yes, even in 2026. Django still works. Instagram was Django at huge scale.
If you've shipped Next.js before, build it in Next.js. Don't switch to Remix because someone on Hacker News said Remix has better routing.
If you've shipped Laravel before, build it in Laravel. PHP is fine. The internet runs on PHP. WordPress runs on PHP. Most of your competitors are running on PHP and lying about it.
If you have no framework experience, the question changes. You're picking a learning curve plus a shipping curve. The frameworks I'd recommend in 2026 for absolute beginners, ranked by learnability, ecosystem, and ability to ship something real:
Next.js with the App Router on Vercel is probably the best general-purpose choice for a typical web MVP. It's TypeScript by default, has good docs, a deploy story that works without thinking, and the most LLM-coding-assistant training data, meaning tools like Claude Code, Cursor, and Copilot will help you most. The negatives are real — the framework is over-engineered for most MVPs, the App Router has rough edges, and you can spend a day fighting hydration mismatches — but those negatives are smaller than picking something with worse AI tooling.
Ruby on Rails 8 is the right answer if you want maximum velocity and you're willing to learn one framework deeply. Rails in 2026 is genuinely better than in 2015 — Hotwire works, Turbo works, the deploy story with Kamal is good. The hiring market for Rails developers is worse than it used to be, which matters if you intend to hire engineers. For a solo or small-team MVP, that doesn't matter.
Django + HTMX is a slept-on combination. You get Python (easy ML integration, good library ecosystem, decent AI-assistant support), Django's batteries-included approach (admin panel, ORM, auth, migrations), and a frontend story (HTMX) that doesn't require building a separate SPA. The total complexity is much lower than the React/Next.js variant. If your MVP doesn't need a complex frontend, this is faster than any JavaScript option.
Phoenix on Elixir if you have an excuse to use it. Excellent for real-time features (chat, live updates, multiplayer). LiveView is genuinely a different paradigm and it's good. The downside is the ecosystem is smaller and AI tooling assistance is worse. Worth it if your product is real-time-first.
Laravel if you already know PHP or have a PHP-experienced co-founder. Modern Laravel is genuinely good. The deploy story is well-trodden. The downside is the same as Rails — smaller and shrinking hiring market — and again, doesn't matter for the MVP.
What I would not recommend in 2026 for a first MVP from a beginner:
Anything microservices. You're one person. You don't need three services. You need one service that works.
Anything Kubernetes-first. You don't need Kubernetes. You need a Heroku-shaped deploy target (Heroku itself, Render, Fly.io, Railway, Vercel). Kubernetes is a tool for a problem you do not yet have.
Anything edge-first. Cloudflare Workers, Deno Deploy, and similar are great technologies but constrained — no long-lived connections, limited compute, weird storage stories. Use them for specific edge cases, not as your primary substrate.
Anything Rust. Rust is a great language. It is slow to write in. You will ship 2-4x slower than you would in any of the above. There are real cases where the Rust performance pays back, but they are not MVP cases. If you find yourself reaching for Rust because it's "the right tool," you've optimized for the wrong axis.
Anything custom-built. Building your own framework is the most expensive form of procrastination available to engineers. Don't.
What matters more than the framework choice is the substrate choices around the framework. Database: Postgres. Always Postgres. Don't use MongoDB, MySQL, or DynamoDB for an MVP. Postgres is boring and right. Auth: use the platform (Clerk, Supabase Auth, NextAuth, Devise, whatever) — don't build it yourself. Payments: Stripe, hosted checkout, don't write payment code. Email: Postmark or Resend. File storage: S3 or R2. Deploy: a managed PaaS. The decision tree around the framework is "use the standard well-known thing for everything you don't have to differentiate on," and the framework is just one node in that tree.
A specific framing that helps. When someone asks me "should I use Next.js or Rails," I ask: "what specifically would be different about the customer experience if you picked one versus the other?" Almost always, the honest answer is "nothing." The customer doesn't know what framework you used. They know whether your product is good. The framework affects your internal velocity, not the output. So pick the one that maximizes your velocity, which is the one you know.
Once you have product-market fit and you're scaling, the framework choice will be revisited. That revisit is healthy. Many successful companies were rewritten once or twice as they scaled — Twitter went Rails to Scala, Shopify is still Rails but has carved out components, Stripe started in PHP and is now mostly Ruby and Scala, Facebook started in PHP and built Hack to keep PHP at scale. The pattern is: ship in the language you know, get to PMF, then rewrite the parts that need to be rewritten with the benefit of knowing what your actual workload looks like. That's a much better path than spending six months in framework-selection paralysis pretending you know what you'll need at scale.
So: which framework should you use? The one you know. If you don't know any, pick Next.js or Django and start building. The framework will not save a bad business idea. The framework will not kill a good business idea. The market will. Go meet the market.