We Didn't Switch to TanStack. We Built a Company on It.
The industry might call what we're building a vibe coding platform. We're not. We're building an engineering platform.
That distinction matters. Because when you're building software that other people will maintain, debug, and grow -- you make a choice pretty early:
Do you want your AI to generate code that looks right... or code you'd actually ship?
Early on, we made a bet that shaped everything about how our product works today: every project we generate is built on a fully type-safe stack -- TanStack Start + TanStack Router, Drizzle ORM, and other libraries that share the same philosophy of type safety from the ground up.
And yes -- that was an "are you sure about this?" kind of decision.
I committed to TanStack Router when it was still in beta. Then to TanStack Start when it was first announced. Plenty of teams would've defaulted to something safer, more established, more obviously "production." We could've done that too.
But we're not building another scaffolding tool. We're building an end-to-end software development platform -- one where the AI writes real software, from architecture to deployment. And to write software we're proud of, our AI needs one thing more than anything else:
constraints.
We use strong opinions. We use best practices. But above all else, we need constraints the compiler enforces.
That's why we chose TanStack.
This isn't our first experiment -- it's the result of years of them
I've been working on Sedrino for over two years now, trying to figure out what AI-assisted software development would actually look like -- even when the models weren't capable of it yet.
That meant a lot of experiments. A lot of wrong turns. A lot of building things before the ecosystem was ready for them. All of it led us to what we're building today: a ticket-based AI programming agent for TanStack. You describe what you want, and our AI engineers it -- writing real, type-safe, production-grade code across your entire application.
The common thread across everything we tried: the output quality ceiling is set by the stack you target.
You can improve prompts. You can fine-tune models. You can build better scaffolding. But if the underlying framework doesn't enforce correctness at the type level, you're always fighting the same battle -- AI that produces code that looks right but silently breaks in ways you won't catch until production.
That's the lesson that led us to TanStack. Not a blog post. Not a conference talk. Years of building and watching where things fall apart.
What we considered (and why we kept coming back to TanStack)
When we started building Sedrino, we had the same options every team has. React Router for an SPA. Next.js for the "obvious" full-stack choice. As someone who's been developing software for 15 years, none of them felt right -- not because they're bad tools, but because none of them were built for the problem we're solving: AI writing code that humans will own.
Honestly, most of these I just didn't have a taste for. If you'd forced me to pick one back then, I'd have gone with React Router and a Hono backend -- keep it simple, keep the pieces separate, stay close to the metal. But even that combo didn't give us what we really needed for AI-generated output.
React Router (which now includes what used to be Remix, merged together as React Router 7) is battle-tested and ubiquitous. I respect what the team has built and the direction they've taken with the Remix merger. But at its core, type safety has been bolted on over time rather than designed in from the start. Search params are still essentially untyped strings you parse yourself. For a human building a single app, that's fine. For an AI generating thousands of variations that need to be correct by default, it's a liability. There's no compile-time contract for the AI to build against -- just conventions it has to hope it gets right.
Next.js was the most obvious choice, and credit where it's due -- it brought server-rendered React to the mainstream and built an enormous ecosystem around it. A lot of great software has shipped on Next.js. But I had strong opinions, even back then, that it wasn't where things were headed. The constant paradigm shifts -- Pages Router to App Router, new data fetching patterns every major version -- made it hard to feel confident building a stable generation target on top of it. And for our specific use case, the framework's conventions lean heavily on filesystem routing and string-based paths rather than typed structures an AI can validate against at compile time. I'll leave it at that -- plenty of teams ship great products with Next.js, it just wasn't the right fit for what we're building.
What the TanStack team was building was different. It wasn't chasing paradigm shifts or platform lock-in. The vision was clear: strong, composable primitives with type safety designed in from day one. Routes as typed structures, not filesystem conventions. Search params as validated schemas, not string soup. A full-stack story built around the same type-safe routing core, with Vite underneath and deployment flexibility by default. That clarity of vision -- and the discipline to execute on it without constant reinvention -- is what made us confident enough to bet on TanStack Router in beta and TanStack Start before it was anywhere near stable.
From Hono + Router to a full TanStack architecture
We were already committed to TanStack Router. Our original stack was TanStack Router paired with a Hono backend -- the same combo I would have reached for personally. It was working. The routing layer was type-safe, the backend was fast and minimal, and the pieces were cleanly separated.
Then TanStack Start was announced.
We saw what it meant immediately: the same type-safe routing core we'd already bet on, extended into a full-stack framework. Server functions, data loading, server/client boundaries -- all built on the foundation we were already using, with the same philosophy of explicit, composable, type-forward design.
So we pivoted from Hono + TanStack Router to a full TanStack architecture.
That wasn't a small decision. But it was an obvious one. Start gave us:
- A unified type-safe story from route to server function
- The same router we'd already built around, now with full-stack capabilities
- Vite underneath, with deployment flexibility by default
- No vendor lock-in, no platform coupling
We could've stayed with Hono + Router. But Start meant we didn't have to maintain two separate paradigms for the frontend and backend -- our AI could generate a single, cohesive full-stack application where everything speaks the same type language.
That bet cost us time -- and we'd make it again
Let's be honest about what choosing TanStack meant in practice: it slowed us down.
If we'd picked Next.js or even React Router, we could have shipped a product sooner. The frameworks were stable. The ecosystems were mature. The AI models already had them in their training data. We could have hit the market faster and figured out the rest later.
Instead, we chose a stack where we had to wait on two fronts at once.
First, we needed TanStack Start to stabilize. We committed early, which meant building on a moving target -- tracking breaking changes, adapting to API shifts, and sometimes just waiting for features to land. That's the tax you pay for betting on something before it's "ready."
Second -- and this is one people don't talk about enough -- we needed the AI models themselves to get better. TanStack Router and Start weren't in the training data of early models. They didn't know the APIs. They couldn't follow the patterns. We couldn't just point an LLM at TanStack and expect good output the way you could with Next.js or React Router, which had years of Stack Overflow answers and blog posts baked into every model's weights.
We had to wait for models to get good enough at following instructions and documentation -- at working from reference material rather than memorized patterns. That's a fundamentally different capability, and it took time to arrive.
Both of those constraints have largely resolved. TanStack Start is approaching stability. Modern models can work from docs, not just training data. And because we did the hard work of building our generation pipeline around TanStack's type-safe foundations from the start, we're not scrambling to retrofit correctness onto a stack that was never designed for it.
The teams that shipped faster on easier stacks are now hitting the ceiling we saw coming. We'd rather be late and right than early and stuck.
Types matter more when the author is AI
A lot of "AI generates an app" products quietly aim for a shallow goal: generate something that runs. Our bar is different: generate something you can maintain.
That changes everything about how you pick a stack. Because for us, the output isn't just a runtime -- it's a build target that our AI has to hit reliably across thousands of variations. And the single most important property of that target is type safety.
Humans are great at context and intent. We can hold a fuzzy mental model and still land the plane. AI is different. It's incredibly capable, but it's also probabilistic. It will confidently produce something that "seems plausible" even when it's subtly wrong.
Types turn that into a strength. Types give the AI a contract, a feedback loop, a way to self-correct, a way to refactor without guessing, and a way to produce code that stays correct as it grows. If you want AI-generated apps to be more than demo-ware, you need an ecosystem where "wrong" is detectable early and consistently.
TanStack Router delivers this in the place it matters most: routing. A surprising amount of app complexity lives in routes, params, search params, data loading, and navigation. In most ecosystems, these are effectively strings plus convention -- easy for AI to produce and easy to get subtly wrong. TanStack Router makes them typed structures. The AI builds against a shape, not a vibe. Mistakes become compiler errors instead of runtime bugs. That's not just nice DX -- that's AI viability.
The same applies to URL state. In most stacks, search params are untyped string soup. Humans can manage that with discipline. AI will eventually make it weird. TanStack Router's typed search params mean our AI can declare what valid search params look like, validate inputs, keep state consistent across links, and refactor across route changes without breaking deep links. A lot of apps feel "real" only once URLs behave like real application state -- and type safety is what makes that generatable.
We needed a stack that is predictable, type-forward, explicit about data and routing, friendly to refactors, and hard to accidentally misuse. TanStack checked every box.
The bet we're making
Over two years ago, I started building Sedrino because I believed AI would fundamentally change how software gets written. Not just faster. Not just cheaper. Differently.
Most of that time was spent being wrong about the details and right about the direction. The models got better. The tooling caught up. And along the way, one conviction never wavered:
The stack you target determines the ceiling of what AI can build.
Pick a stack full of conventions, magic, and string-based contracts -- and your AI will produce code that works until it doesn't, in ways nobody can debug.
Pick a stack built on types, composability, and explicit boundaries -- and your AI produces code that a senior engineer would actually be proud to review.
We didn't choose TanStack because it was trendy. We didn't choose it because we wanted to be early. We chose it because it aligns with what we want AI-generated software to become: explicit, type-safe, maintainable, refactorable, understandable by real developers, and worthy of long-term ownership.
When your AI writes code, your users inherit it. They live in it. They debug it. They onboard teammates into it. We want them to look at the output and feel: "This is clean. This is modern. This is mine."
TanStack -- especially Router, and now Start -- is the clearest expression of that future we've found. It's not perfect. It's not finished. But the vision behind it is exactly where software development needs to go, whether a human is writing the code or an AI is.
So we chose it early. We built on it. And we're still building.
If you want to see what that looks like in practice -- a ticket-based AI agent that engineers real TanStack applications -- go give it a try at sedrino.com.