We ditched Next.js. Not because it's bad — it's excellent for many use cases. But because we realized something fundamental: the framework matters less than the consistency.
After two years of building AI products across multiple portfolio companies, we've learned that the real competitive advantage isn't choosing the "best" tool for each project. It's choosing tools once, getting absurdly good at them, and reusing that expertise relentlessly.
Welcome to our unified stack philosophy.
The Problem: Framework Fatigue is Killing Velocity
Here's what was happening before we standardized:
Project A: Next.js 14 with App Router Project B: Next.js 13 with Pages Router Project C: Remix because "it's the future" Project D: Next.js 15 because why not
Every. Single. Project. Required. Learning. Again.
Not just learning—relearning. "Wait, how do we handle server actions in this version?" "Does this one support RSC?" "Which routing paradigm are we using here?"
The result? Our senior engineers spent 30% of their time just remembering which patterns worked in which framework version. New hires took 3-4 weeks to become productive. Debugging across projects meant context-switching through three different mental models.
That's not engineering. That's waste.
The Breaking Point: The Next.js 14 Migration
The moment we decided to switch wasn't dramatic—it was exhausting.
We had a portfolio company on Next.js 13 Pages Router. Production-stable, no issues. Then we started a new feature requiring SSR streaming. The docs said "just upgrade to App Router."
Three weeks later:
- 47 files refactored
- 12 "gotchas" that weren't in the docs
- 5 packages incompatible with App Router
- 2 senior engineers pulling all-nighters
- 1 deployment that broke auth because server components work differently
The feature worked. But we'd spent more time fighting the framework than building the feature.
This wasn't Next.js's fault—it's evolving rapidly, which is good for the ecosystem. But for a venture studio building 6-8 products simultaneously, rapid evolution is a liability, not an asset.
Why TanStack Start?
We didn't choose TanStack Start because it's "better" than Next.js. We chose it because it aligns with how we want to build.
1. Client-First Philosophy
TanStack Start is unapologetically client-first with opt-in SSR. This matches our AI product reality: most of our apps are interactive SPAs with server-rendered marketing pages, not content-heavy websites.
Next.js forces you to think server-first. Which is great for blogs, e-commerce, and content sites. But for real-time AI applications with complex client state? It's friction.
Example: Our RAG-powered document assistant needs client-side state for:
- Real-time streaming LLM responses
- Document preview with annotations
- Chat history management
- WebSocket connections for collaborative editing
With Next.js App Router, this meant fighting RSC boundaries, understanding "use client" vs "use server," and debugging hydration mismatches.
With TanStack Start? Client by default. Add server functions where needed. Done.
2. Type Safety That Actually Works
TanStack Router (the foundation of TanStack Start) gives us end-to-end type safety from routes to params to loaders to components.
This means:
// Define route
export const Route = createFileRoute("/projects/$projectId/documents/$docId")({
loader: async ({ params }) => {
// params.projectId is typed as string
// params.docId is typed as string
return getDocument(params.docId);
},
});
// Use in component - fully typed
function DocumentView() {
const { projectId, docId } = Route.useParams(); // both typed!
const document = Route.useLoaderData(); // typed from loader!
}
Contrast with Next.js dynamic routes:
// params might be string | string[] | undefined
// You're on your own for typing
function Page({ params }: { params: any }) {
const docId = params.docId; // hope it's there
}
This isn't a small difference. Type safety in routing eliminates entire classes of bugs. Refactoring routes? TypeScript tells you every component that breaks. In Next.js? Runtime errors in production.
3. Vite Build Performance
Cold starts:
- Next.js: 8-12 seconds
- TanStack Start (Vite): 1-2 seconds
This compounds. Our engineers save ~45 minutes per day just from faster dev server starts. Across 6 engineers, that's 4.5 hours daily. Over a month, that's 90 hours saved—more than two work weeks.
4. Less Magic, More Control
Next.js has a lot of magic:
- Automatic API routes in
/pages/api - Automatic static optimization
- Automatic code splitting
- Automatic image optimization
Magic is great until it isn't. When something breaks, you're debugging the framework's decisions, not your code.
TanStack Start is explicit:
- Want server functions? Define them explicitly
- Want code splitting? Configure it
- Want SSR? Opt in per route
Explicit > implicit when you're building products that need to ship reliably across multiple companies.
Our Unified Stack Philosophy
TanStack Start isn't alone. It's part of our complete standardized stack:
Frontend
- TanStack Start: Full-stack React framework
- TanStack Router: Type-safe routing
- TanStack Query: Data synchronization (we use this EVERYWHERE)
- Tailwind CSS: Styling (utility-first is perfect for consistency)
Backend & Infrastructure
- Control Plane: Multicloud infrastructure (AWS, GCP, Azure—one interface)
- PlanetScale: PostgreSQL (serverless, branching, no migration headaches)
- Mirascope: LLM framework (Elegant agent orchestration, no need to learn a new framework)
- TurboPuffer: Vector database (fast, simple, no pricing surprises)
Why This Stack?
Not because each tool is "the best." Because:
- Consistency compounds: Same tools across all projects = shared knowledge
- Onboarding is fast: New engineers learn once, contribute everywhere
- Debugging is faster: Same patterns, same tools, same solutions
- Cross-project improvements: Optimization in Project A helps Project B
- Maintenance is sane: One upgrade path, not six
The Results: Quantified Benefits
After 6 months on the unified stack:
Developer Velocity:
- Onboarding time: 3-4 weeks → 1 week
- Context switching overhead: ~30% → ~5%
- Cross-project contribution: rare → common
- "How does this work here?" questions: constant → rare
Deployment Reliability:
- Deploy confidence: 60% → 95%
- Rollback frequency: 2-3/month → 1/quarter
- "Works on my machine" incidents: weekly → never
Engineering Satisfaction:
- "I feel productive quickly": 40% → 90%
- "I understand the stack": 50% → 100%
- "I can help across projects": 30% → 85%
Actual Time Savings:
- Dev server start time: 8-12s → 1-2s (~45 min/day/engineer)
- Debug time (cross-project issues): 4-6 hours → 30-60 min
- Knowledge transfer (between engineers): formal sessions needed → organic osmosis
What We Gave Up
Let's be honest about trade-offs:
1. Next.js Ecosystem
Next.js has more tutorials, more starter templates, more "copy-paste solutions" on Stack Overflow. TanStack Start is newer (currently in Release Candidate stage, approaching v1.0 stable), so you'll build more from scratch.
Why we're okay with this: We're a venture studio. We build custom products. Starter templates rarely match our needs anyway. We'd rather have a consistent foundation than 1,000 half-relevant tutorials.
2. Vercel Deployment Magic
Next.js on Vercel is genuinely magical. Push to GitHub, it deploys. Edge functions, image optimization, analytics—all integrated.
Why we're okay with this: TanStack Start's deployment flexibility is actually a massive advantage. Unlike Next.js (which pushes you toward Vercel), TanStack Start works seamlessly with multiple providers:
- Cloudflare Workers/Pages: Full support with the Cloudflare Vite plugin—fast edge deployments globally
- Netlify: Official deployment partner with first-class support
- AWS, GCP, Azure: Deploy anywhere via Control Plane or direct deployment
- Any Node.js environment: No vendor lock-in whatsoever
This means our portfolio companies can choose their cloud provider based on their actual needs (compliance, cost, existing infrastructure), not our framework's preferences. One company uses Cloudflare for edge performance, another uses AWS for compliance, another uses GCP for ML integration—all running the same TanStack Start codebase.
3. Fewer "Ready-Made" Solutions
If we were building content-heavy sites (blogs, documentation, e-commerce), Next.js's server-first approach and extensive e-commerce integrations would be valuable. SSR by default, static generation, ISR—all excellent for content.
Why we're okay with this: We're building AI applications. Interactive dashboards, real-time data, streaming responses, client-heavy state. Client-first fits our reality better, and we'd rather have deployment flexibility than framework magic that works best on one platform.
When You Should NOT Switch
TanStack Start isn't for everyone. Stick with Next.js if:
- You're building content-first: Blogs, marketing sites, e-commerce
- You're solo/small team: Next.js's ecosystem will save you time
- You're already productive: If Next.js works for you, don't fix what's not broken
- You're okay with Vercel lock-in: If you're committed to Vercel's ecosystem and don't need multi-cloud flexibility
The Deeper Philosophy: Consistency > Novelty
This isn't really about Next.js vs TanStack Start. It's about engineering philosophy.
The tech industry worships novelty. New frameworks, new paradigms, new "best practices" every quarter. This is fine for individual developers exploring and learning.
But for a venture studio building products that need to:
- Ship reliably
- Scale predictably
- Maintain sanely
- Evolve sustainably
Novelty is expensive. Consistency compounds.
Every time you switch tools, you reset your expertise to zero. Every time you use different tools across projects, you fragment your team's knowledge. Every time you chase "the best," you waste time that could be spent building.
We'd rather be world-class at 6 tools than mediocre at 60.
Our Stack Selection Framework
How do we decide what goes in the unified stack?
1. Does it solve a real problem?
Not "is it interesting?" but "do all our projects need this?"
2. Can we master it?
Can our team become experts in 3-6 months?
3. Is it stable enough?
Not "production-ready" but "won't change fundamentally in 2 years"
4. Does it compose well?
Does it play nicely with our other tools?
5. Is the community healthy?
Will it be maintained? Will we find answers to hard questions?
TanStack Start (plus the rest of our stack) passes all five.
Looking Forward
We're not done. Our unified stack will evolve as:
- TanStack Start reaches stable release
- Better tools emerge for specific needs
- Our portfolio companies expose new requirements
But we'll evolve deliberately. Not chasing hype. Not switching because "everyone's talking about it."
We'll switch when the benefits of a new tool clearly outweigh the cost of resetting our expertise and fragmenting our knowledge.
Until then? We're getting absurdly good at the tools we have.
Try It (Maybe)
If you're considering TanStack Start, here's my advice:
Start small: Build a side project or internal tool, not your main product Leverage TanStack Query: If you're already using React Query, TanStack Start feels natural Embrace type safety: The routing types are the killer feature—lean into them Read the migration guide: TanStack has excellent docs for migrating from Next.js Join the community: TanStack Discord is active and helpful
But also: if Next.js is working for you, don't switch. Seriously. The best framework is the one you're productive in.
For us? TanStack Start fits how we build. And more importantly, having ONE framework across all projects is the real win.
The Unified Stack Series
This is part 1 of our Unified Stack series. Coming next:
- Part 2: Why We Chose Control Plane for Multicloud Infrastructure
- Part 3: Mirascope vs LangChain: The LLM Framework Battle
- Part 4: TurboPuffer: Fast Vector Search Without the Enterprise Tax
- Part 5: PlanetScale PostgreSQL: Performance and Control Over Platform Lock-in
Want to see how we build AI products with our unified stack? Check out our About page or reach out to discuss your AI project.
