The Vibe Coder's Launch Stack: What You Actually Ship When the AI Is Done

Cursor, Claude Code, Windsurf, OpenCode — the authoring tools get the spotlight. The real decision is what you deploy. An opinionated tour of the stack that's quietly eating AI-built apps.

I’ve just spent four hours vibe coding a working prototype. The model wrote everything — routing, auth flows, a hero section, three forms that validate, a Stripe checkout page. The demo plays clean. The URL is localhost:3000. Now what do I ship to?

That question is where the conversation goes quiet. There are a thousand hot takes a week about Cursor versus Claude Code versus Windsurf versus OpenCode. The authoring-tool war is everywhere. The stack-decision question — what infrastructure you actually deploy on — is where the real leverage lives, and nobody is writing about it with the same energy.

TODO (author): Personal hook. Which vibe coding tools do you use daily, and how did the stack question keep resurfacing after the prototype was “done”? A short day-in-the-life frame before pivoting to the essay.

This post is an attempt at that honest conversation. Opinions, tradeoffs, and a short list of stacks that quietly lose in the age of vibe coding.

The distinction nobody is making

There are three layers, and people keep conflating them.

Authoring tools. Cursor, Claude Code, Windsurf, OpenCode, Cline, Aider, Continue. These are the editors and CLIs you drive the agent from. Switching between them costs a week of muscle memory. They are interchangeable the way vim and emacs were interchangeable — loud tribal preferences, nearly identical outcomes.

Launch stacks. Next.js + Vercel + Supabase. Astro + Cloudflare. Fly + Go + Postgres. This is the actual software you deploy, the platform you bill against, the code you’ll be debugging at two in the morning when traffic spikes. Swapping a launch stack after shipping is measured in weeks or months.

Hybrid middle. v0, bolt.new, Lovable, Replit Agent. Authoring tools with opinionated stacks already welded on. The onramp is smooth and the migration is painful. You start with “pick what you want” and end with “their stack, whether you meant to or not.”

The authoring-tool decision is a this-month decision. The stack decision is a three-year decision. The noise ratio is inverted from the consequence ratio.

What vibe coding actually demands of a stack

The thing a launch stack has to do, specifically for AI-assisted work, is be legible to an agent. That sounds abstract until you watch a capable model flail against a clever but low-legibility codebase. The model isn’t dumb — the architecture is illegible. Here are the five properties that matter, in rough order of importance.

1. Strong types end-to-end. TypeScript. Typed Python with real runtime enforcement. Rust. Go. Every untyped seam is a place where the agent has to guess, and when it guesses it hallucinates a plausible interface that compiles and breaks at runtime. Types are how you pin the agent to reality.

2. Strong conventions. File-based routing. Opinionated layouts. A framework that has one obvious place for everything. The agent writes better code in Next.js than in bare React for the same reason a new hire onboards faster into Rails than into a hand-rolled MVC — fewer decisions to relitigate, fewer ways to be wrong. Rigidity is a feature when your collaborator is an LLM.

3. Fast feedback loops. Sub-second typecheck. Hot reload that actually reloads. Tests that finish in seconds. The vibe-coding loop is prompt → diff → verify. If verify takes thirty seconds, you’ve stopped coding and started compiling.

4. Training-data density. This is the uncomfortable one. Next.js isn’t winning because it’s technically superior to SvelteKit. It’s winning because there are ten times more Next.js repos in the training set, and the model writes working Next code on the first try more often than it writes working SvelteKit code. If you are one person with one life and an agent, you ride this asymmetry. You don’t fight it.

5. Managed boundaries. BaaS — backend-as-a-service — removes entire categories of code where LLMs are at their worst. Password hashing. Session invalidation. Email deliverability. Webhook signature verification. You don’t want the agent hand-rolling any of that. You want it gluing to a service that handles it correctly.

A stack that misses any of these five is a stack the agent will fail you on. Not dramatically — the demo will still work — but in the long slow way where shipping velocity degrades and you can’t quite say why.

The emergent default stack

Here is what the modal 2026 stack looks like, if you squint across every Lovable landing page and every v0-generated SaaS:

Next.js App Router for the framework
TypeScript everywhere
Tailwind v4 for styling
shadcn/ui for components
Supabase or Convex for the database and auth
Clerk for auth when Supabase auth isn’t enough
Stripe for billing
Resend for transactional email
Vercel AI SDK for model calls
Vercel for hosting

This stack wasn’t chosen. It emerged. I’ve started calling the phenomenon LLM gravity. The feedback loop goes: training data density → agent reliability → more apps shipped on that stack → more repos in the next training run → more density. Self-reinforcing. Next is winning because the models write it right on the first try, not because App Router is definitionally the best way to build a web app.

That isn’t a complaint. It’s a selection pressure to understand. If you are building alone with an agent, you ride the gravity well. You accept it, use it, know what you gave up, and don’t pretend you made a pure-merit decision.

TODO (author): Do you buy the “LLM gravity” framing? Any war stories from fighting a non-default stack — where the agent kept writing the wrong thing because the training data wasn’t there?

Variations by app type

The default stack is wrong for several kinds of products. The taxonomy I’ve settled on, honestly ranked:

Content / marketing / portfolio sites. Astro, not Next. MPA-by-default, MDX-first, zero JavaScript shipped unless you ask for it. Agents write Astro routes and Tailwind components cleanly, and the resulting site weighs less than a tweet.

TODO (author): HerdingBots.ai runs on exactly this stack (Astro + Tailwind v4 + MDX + a VPS with rsync deploys). A sentence or two about what that’s been like to build with an agent — what worked, what didn’t.

AI-native SaaS with real-time reactivity. Convex. Its reactive-function model maps unusually cleanly onto how agents reason about data flow. You write a function, the rest of the graph recomputes. No cache invalidation, no fanout code. For an AI-native product this ends up feeling like home.

Traditional CRUD SaaS. Next + Drizzle + Neon + Clerk. Drizzle beats Prisma for agent legibility — the schema is a TypeScript file the agent can read directly, not a DSL that gets compiled into types the agent can’t see the source of.

AI wrapper / chat product. Next + Vercel AI SDK + Upstash Redis + your LLM provider of choice. Skip LangChain unless you need a specific piece of it. The default SDK does streaming, tool calls, and provider abstraction without the ceremony.

Mobile MVP. Expo + EAS + Convex or Supabase. React Native is the only mobile stack the agent writes reliably. Native Swift and Kotlin work; Flutter has a training-density problem you will feel on week two.

Internal tools. Next + Supabase + Clerk. Retool used to be the answer. The agent is cheaper, faster, and the result is code you own.

Blog or publication. Astro + MDX, unless you have non-technical editors, in which case Next + Sanity. Either one is better than WordPress in 2026 for an AI-built site.

API-only service. Hono or Fastify on Node, or Fiber on Go. Deploy on Fly or Render. Small, strongly-conventioned, easy to reason about.

You don’t have to follow any of this, but notice the common thread: the stack is always legible first.

BaaS is the unsung layer

Here’s the piece of the conversation I wish got more attention. The agent is exceptional at glue code and dismal at infrastructure. You want to push every category of code that isn’t your product into a managed service. Not because the service is cheap — some of them aren’t — but because each one removes a class of bug the agent was never going to get right.

The working map:

Auth: Clerk or Supabase auth. Do not roll your own. “Probably fine” is not the adjective you want attached to password handling.
Payments: Stripe, full stop.
Transactional email: Resend or Postmark. Deliverability is a whole career; outsource it.
File storage: Cloudflare R2 or Supabase Storage. Presigned URLs, S3-compatible, predictable billing.
Background jobs: Inngest or Upstash QStash. Retries, dead-letter queues, observability. The agent should not be writing a cron server.
Realtime: Convex if you’re already on Convex; Supabase Realtime otherwise. Websocket plumbing is a tarpit.
Error monitoring: Sentry. Still the right answer.
Log aggregation: Axiom or Better Stack. Something beyond console.log.
Analytics: PostHog for product analytics, plus whatever marketing tracker you’re required to add.
Rate limiting: Upstash Ratelimit or Cloudflare’s edge rules. Not a middleware you hand-roll.

Every one of these is a seam where, in the pre-AI era, a team would have had a specialist or a multi-month project. In the vibe-coded era, they are one-line integrations, and the ROI per integration is obscene. The cognitive load you save by not having to reason about webhook signature verification is cognitive load you spend on the product.

Databases and deploy targets, ranked honestly

For databases, the ranking I use:

Postgres (Neon, Supabase, Railway, or self-hosted). Wins everything. The agent knows SQL, knows Postgres-specific features, knows common extensions. There is no category where Postgres is not at least second best.
SQLite / Turso. Great for edge-first apps and small data footprints. Agent writes it well. Limits on writes if you outgrow a single primary.
Convex built-in. If you’re on Convex, use it. Don’t fight the grain.
DynamoDB / Firestore. Reasonable for specific shapes. Agent writes acceptable code against them but makes pagination mistakes that cost money in read units.
MongoDB. Do not pick this because the agent defaults to it. It will compound schema drift over the lifetime of the app.

For vector search: pgvector wins for 95% of cases. Skip Pinecone, Weaviate, and Qdrant until you have measured a real scaling limit in Postgres and hit it. “The vector DB is the AI piece” is a 2023 mental model; the vector index is just another index in 2026.

For deploy targets:

Vercel. Default for Next. Brilliant DX. Pricing cliffs are real — bandwidth, function duration, compute tier. Plan your escape hatch before you need it.
Cloudflare. Cheap, fast, runs almost everywhere. Runtime quirks (Workers ≠ Node) catch the agent off guard; expect to give it hints about what APIs exist in the Workers runtime.
Fly.io. When you need a stateful server, a long-running process, or a region you control. The agent writes fly.toml badly the first time; good the second.
Render / Railway. Docker push and forget. Good for APIs and workers. Billing is saner than Vercel at scale.
Your own VPS. Only if you know why. Real answer: rsync a static site to a box you already own and never think about it again.

TODO (author): What do you actually deploy to? LiteLedger.ai stack, HerdingBots’ rsync-to-VPS setup, any pricing horror stories from Vercel or wins from a cheaper alternative.

What this stack costs you

I’m going to say the things opinionated posts usually dodge.

The default stack has real downsides, and if you skip this section the whole piece reads like a sales pitch for Vercel.

Vendor lock-in. Migrating off Vercel is an engineering project. Moving a Supabase database to self-hosted Postgres is another one. Convex queries don’t translate cleanly to Postgres. You are buying time and DX, and the bill eventually comes due.

Pricing cliffs. Vercel’s tiers have edges that cost serious money if your traffic pattern is spiky. Supabase’s row count and storage tiers bite at exactly the moment you’re too busy to migrate. Budget for the cliff before you hit it.

Stack homogeneity. Your architecture is now indistinguishable from every other SaaS shipped this year. That is partly the point — you picked what the agent knows — but it means your competitive edge has to come from product, not from a novel substrate. Which was true anyway, but it’s sharper now.

Monoculture risk. When Vercel has a bad day, half the modern web has a bad day. That correlated failure mode didn’t exist five years ago at this scale.

“Works on my Vercel.” Local and deployed runtime divergence is a slow-burn category of bug. Edge functions run differently. Cold starts hit different paths. You will spend an afternoon, someday, debugging a thing that worked in dev and failed in prod for no reason the agent can see. This is the tax.

Name these, accept them, decide it’s worth it. Or don’t, and pick something else. Either answer is legitimate. Pretending the tradeoffs aren’t real is not.

Stacks that lose in the age of vibe coding

The controversial section. These are good stacks, in many cases technically better stacks, that are wrong for AI-assisted work right now. “Right now” is load-bearing — training-data density will shift, and some of this list will become obsolete.

SvelteKit. About 20% more iterations to get an agent to write correct code versus React. The framework is elegant, the DX is great, and you will feel it every session. Wait for the training-density gap to close.

HTMX-only. Thin training data, and the agent mixes idioms across versions. You’ll spend sessions correcting “why did you import jQuery?” when you didn’t ask for jQuery. If you love HTMX, use it inside a conventional framework, not as the spine.

Full Django or Rails monoliths for AI-native products. Both are excellent frameworks. The two-language context switch — backend in Python or Ruby, frontend still in TypeScript — kills the vibe-coding iteration loop. The agent can do it, it’s just slower than an all-TS codebase, and slower compounds.

Flutter. Far less training data than React Native. The agent writes passable Dart and then subtly wrong widgets. Unless you have a team fluent in Flutter already, React Native is the default.

Self-hosted Kubernetes for an MVP. Wrong complexity-to-leverage ratio. An MVP does not need the platform a Fortune 500 needs. You will spend more time on cluster lifecycle than on your product.

Your own auth. Covered above. Nothing has changed.

Any stack you have to re-explain to the agent every session. If every new conversation starts with “remember, we use the custom X pattern instead of Y” — the stack is failing the legibility test in real time. Either document the pattern well enough that one CLAUDE.md file fixes it permanently, or move to the default.

Five rules for picking

Pick what the agent knows best unless you have a named reason not to. “I like this framework more” is not a named reason. “My users need sub-50ms P99 latency and only Fly supports the region” is.
Push everything that isn’t your product to a managed service. Every integration you skip is a category of bug you don’t ship.
Types end-to-end, no exceptions. Strings-as-IDs across service boundaries are where the agent starts to drift.
Strong conventions beat flexible configuration. The framework that makes one choice for you is the framework the agent will write correctly.
You can be 80% right in twenty minutes — the stack isn’t the product. Every hour you spend on stack bikeshedding is an hour you didn’t spend on the thing customers actually pay for.

The takeaway

The tool war is taste. The stack is leverage.

Cursor and Claude Code and Windsurf will all write your application. They matter for how you work, not for what you ship. You can swap between them over a weekend. Your users never notice.

The stack is different. The stack is the thing you’ll still be on three years from now. The stack is what decides whether the agent is your leverage or your anchor. Pick the stack the agent already knows, push the non-product work to managed services, keep the types tight and the conventions opinionated, and get back to the only part that matters — the product.

TODO (author): Closing personal note. Your preferred stack, opinionated sign-off, and — optional — a tease of the next post if you want one (“Part 2: the authoring-tool comparison nobody wants to write,” etc.).

The AI is an extraordinarily good builder. Give it a good workbench.