Stu Mason
Stu Mason
Guide

MVP Tech Stack Decision Tree: Laravel, Next.js, Rails, or Django

Stuart Mason7 min read

Here's the dirty secret about tech stack decisions: the best stack is the one your team knows. That's it. That's the tweet. But since you're here for more nuance than that, let's get into it. ### Th

MVP Tech Stack Decision Tree: Laravel, Next.js, Rails, or Django

Here's the dirty secret about tech stack decisions: the best stack is the one your team knows. That's it. That's the tweet.

But since you're here for more nuance than that, let's get into it.

The Actual Decision Framework

Before we compare frameworks, answer these questions:

  1. Who is building this? One developer? A team? What do they know?
  2. What does the product need to do? CRUD? Real-time? Heavy computation? Content-heavy?
  3. How important is time to market? Weeks? Months?
  4. What's the hiring plan? Will you need to hire developers later?
  5. Does this need a mobile app? Now or in the future?

Your answers to these five questions narrow the field more than any framework comparison ever will.

Laravel + Inertia: My Default Choice

Full disclosure: I'm biased. I've been writing Laravel for over a decade. But I'm biased because it keeps proving itself as the right choice for the projects I work on.

Best for: SaaS applications, marketplaces, admin-heavy tools, anything with complex business logic, projects where one developer needs to move fast.

The stack: Laravel 12 + Inertia v2 + React 19 + TypeScript + Tailwind v4. One codebase, one deployment, full-stack type safety with Wayfinder.

// A complete feature endpoint in Laravel + Inertia
Route::get('/dashboard', function () {
    return Inertia::render('Dashboard', [
        'stats' => DashboardStats::forUser(auth()->user()),
        'notifications' => fn () => auth()->user()
            ->unreadNotifications()
            ->latest()
            ->limit(5)
            ->get(),
    ]);
})->middleware('auth');

Why it wins for MVPs:

  • Authentication, authorisation, queues, mail, broadcasting — all built in and production-ready
  • Eloquent ORM means you can iterate on your database schema fast without fighting your tools
  • Inertia eliminates the API layer, which saves weeks of development time
  • The Laravel ecosystem (Cashier for Stripe, Socialite for OAuth, Horizon for queues) means you're not building commodity features from scratch
  • PHP hosting is cheap and available everywhere

Where it struggles:

  • If your entire team is JavaScript developers, the context switching isn't worth it
  • Static site generation isn't Laravel's thing (use something else for marketing sites)
  • The PHP ecosystem for machine learning and data science is weak
  • If you need a mobile app from day one, you'll need an API regardless

Next.js: The JavaScript Maximalist Option

Best for: Content-heavy sites, apps where SEO matters for the app itself (not just the marketing site), teams that are all-in on JavaScript/TypeScript, projects that need a mobile app via React Native.

Next.js is brilliant for what it's good at. Server components, streaming, incremental static regeneration — it's technically impressive and genuinely useful.

// Next.js server component — simple and clean
async function DashboardPage() {
    const stats = await getDashboardStats()
    const notifications = await getNotifications()

    return (
        <Dashboard stats={stats} notifications={notifications} />
    )
}

Where it wins:

  • One language, everywhere. If your team thinks in TypeScript, everything flows naturally.
  • Vercel's deployment platform is genuinely excellent (if expensive at scale)
  • React Native for mobile means significant code sharing potential
  • Server components are a real paradigm shift for data fetching

Where it hurts:

  • You need to build or choose every piece of backend infrastructure: auth, database ORM, email, queues, caching. Laravel gives you all of this out of the box. With Next.js, you're assembling it from parts.
  • Prisma is good but it's not Eloquent. The migration story, the seeding story, the factory story — they're all more manual.
  • The churn. Next.js moves fast. Pages Router to App Router was a significant migration. React Server Components changed mental models. If you started an MVP two years ago, you're probably refactoring now.
  • Hosting costs. Serverless functions have cold starts. Edge functions have limitations. Self-hosting Next.js is possible but not the primary supported path.

The Rezzy Story: I used both Laravel and Next.js on Rezzy. The core platform (restaurant management, booking logic, Stripe Connect) was Laravel. The embeddable booking widget was a separate Next.js app because it needed to be lightweight and embeddable on external sites. In hindsight, I might have kept more in Laravel and used a simpler approach for the widget. Two stacks means two sets of deployment concerns, two sets of dependencies, and twice the maintenance.

Rails: The Veteran

Best for: Startups with Ruby developers, CRUD-heavy applications, rapid prototyping, companies that value developer happiness.

Rails is still excellent. Shopify runs on it. GitHub ran on it for years. It's mature, well-documented, and the "convention over configuration" philosophy means less decision fatigue.

Where it wins:

  • rails generate scaffold is still the fastest way to go from nothing to working CRUD
  • Active Record is battle-tested and comprehensive
  • Hotwire/Turbo gives you SPA-like behaviour without a JavaScript framework
  • The Ruby community values code quality and testing culture

Where it struggles in 2026:

  • Hiring Ruby developers in the UK is harder than hiring PHP or JavaScript developers
  • The deployment story is more complex than it used to be (Heroku got expensive, alternatives are less polished)
  • If you want a modern React/Vue frontend, you're essentially in the same position as Laravel + Inertia, but with a smaller ecosystem

Django: The Python Play

Best for: ML/AI-heavy products, data-intensive applications, teams that are primarily Python developers, projects that need tight integration with the scientific Python ecosystem.

# Django REST Framework — clean and predictable
class DashboardView(APIView):
    permission_classes = [IsAuthenticated]

    def get(self, request):
        stats = DashboardStats.for_user(request.user)
        return Response(DashboardStatsSerializer(stats).data)

Where it wins:

  • If your MVP involves machine learning, NLP, data processing, or anything that benefits from pandas/numpy/scikit-learn, Django lets you keep everything in Python
  • Django Admin is the best auto-generated admin panel of any framework. Full stop.
  • The ORM is solid and the migration system is excellent
  • Python developers are everywhere

Where it hurts:

  • Django's frontend story is the weakest of all four options. You're either using Django templates (fine for simple UIs) or building a separate SPA (back to the API problem)
  • The async story is improving but still not as natural as Node.js
  • Package ecosystem for web-specific tasks (payments, email, etc.) is smaller than Laravel's

My Honest Decision Tree

Is your team primarily JavaScript/TypeScript developers?
├── Yes → Next.js (with a proper backend service if needed)
└── No
    ├── Does the product heavily involve ML/data science?
    │   ├── Yes → Django
    │   └── No
    │       ├── Is the team primarily Ruby developers?
    │       │   ├── Yes → Rails
    │       │   └── No → Laravel + Inertia
    │       └── Is the team PHP developers or full-stack generalists?
    │           └── Yes → Laravel + Inertia
    └── Nobody on the team yet?
        └── Laravel + Inertia (largest hiring pool for full-stack in the UK)

What Actually Matters for MVPs

Regardless of which framework you pick:

Speed of iteration beats everything. Your first version will be wrong. Your second version will be less wrong. Pick the stack that lets you iterate fastest.

Don't over-engineer. Microservices, event sourcing, CQRS — none of this belongs in an MVP. Monolith. Single database. Simple deployment. You can extract services later when you actually know what needs to scale.

Pick boring technology. Your tech stack should be the least interesting thing about your startup. PostgreSQL, Redis, a monolith framework, a VPS. Done. Save the innovation for your product.

Plan for the rewrite. Not because you should rewrite (you usually shouldn't), but because accepting that your MVP code won't last forever frees you from analysis paralysis. Ship something. Learn. Improve.

The best MVP tech stack is the one that gets your product in front of users the fastest. For me, that's Laravel + Inertia. For you, it might be different. But if you're spending more than a day deciding on your tech stack, you're procrastinating.


If this resonates, I work with founders directly — from early MVP planning through to scaling.

Get the Friday email

What I shipped this week, what I learned, one useful thing.

No spam. Unsubscribe anytime. Privacy policy.