The Vibe Coding Stack: Tools We Actually Use to Ship MVPs

Vibe coding is only as fast as your toolchain. Here's exactly what we use — and why.

This isn't a sponsored breakdown. These are the tools that stayed in our stack after we tried everything else.

The Editor: Cursor

Cursor is where most of the work happens. It's VS Code with AI built into the core — not bolted on as an extension. The difference matters.

What makes Cursor useful in practice:

• —Cmd+K — Inline edit mode. Select code, describe what you want, get a diff. Faster than copy-pasting into a chat window.
• —Cmd+L — Chat with full codebase context. Not just the current file. Cursor can reference files you haven't opened, infer relationships, and navigate the project.
• —Tab completion — Better than Copilot for multi-line completions because it's aware of what you just did, not just the current cursor position.
• —.cursorrules — A project-level instructions file. We put our stack decisions, code style rules, and "don't do this" patterns here. Cursor follows them consistently.

The thing Cursor is genuinely bad at: architecture. It will happily scaffold a 600-line page component if you don't push back. You have to think structurally yourself.

The AI: Claude

We use Claude (via Cursor's API or the Claude.ai interface) as the primary model. Specifically Claude Sonnet for speed and Opus for anything that needs careful reasoning.

Where Claude outperforms other models for development work:

• —Long context. Paste an entire file, an error trace, and a description of the desired behavior. Claude holds all of it.
• —Explanation quality. When something doesn't work, Claude's diagnosis is usually correct and explains why, not just what to change.
• —Following instructions. Tell it to "use the existing pattern from UserCard.tsx" and it actually does. Other models hallucinate new patterns.

We don't let Claude write security-sensitive code unsupervised. Auth logic, API authorization checks, input validation — we write the structure, Claude fills the implementation, we read every line.

The Stack: Next.js + Supabase + Vercel

For 90% of web products, the decision is already made:

• —Next.js 15 — App Router, RSC, built-in image optimization, API routes, TypeScript first. It's boring in the best way.
• —Supabase — Postgres with a REST API, realtime subscriptions, row-level security, and built-in auth. One platform instead of five.
• —Tailwind CSS — AI is extremely good at writing Tailwind. CSS-in-JS is not worth the tradeoff.
• —Vercel — Zero-config deploy from GitHub push. Preview environments per PR. Edge functions if needed.

We don't bikeshed this. Every hour spent on stack selection is an hour not spent shipping.

For UI: shadcn/ui + v0

When we need UI components fast, we use shadcn/ui as the component primitive layer. Copy-paste components you own, styled with Tailwind, no import from a package you don't control.

For initial prototypes, we use Vercel's v0 to generate a starting point from a prompt, then bring it into the real codebase. The output needs cleanup — v0 doesn't know your design system — but it's faster than starting from a blank file.

For Auth: Clerk

We moved from NextAuth to Clerk for most projects. Clerk handles the UI, email verification, social providers, and session management. You add three environment variables and it works.

NextAuth is fine and we still use it for projects that need custom auth logic. Clerk is the default when the client just needs "users who can log in."

For Payments: Stripe

No alternative. Stripe's documentation is excellent, the webhook system is reliable, and AI knows how to write Stripe integration code well because there's so much training data. Lemon Squeezy is good for digital products that need tax handling out of the box.

What We Don't Use (and Why)

Firebase. Vendor lock-in is real. When you want to write a complex query, you'll miss SQL.

Redux. React Query or SWR for server state. Zustand for client state when Context isn't enough. Redux is too much ceremony for an MVP.

Custom component libraries. Don't build a design system before you have a product. Use shadcn, customize what you need, move on.

Microservices. A monolith is the right default. Split when you have a concrete reason, not a hypothetical one.

The Workflow That Actually Works

1. —Define the data model before writing code
2. —Scaffold with Cursor, not manually
3. —Build feature by feature (end-to-end), not layer by layer
4. —Read every file Cursor generates before it stays in the codebase
5. —Manual test the happy path and the sad paths
6. —Audit before launch, every time

The tools are accelerators. The workflow is what determines whether the product ships.

Frequently Asked Questions

Do you use GitHub Copilot?

Occasionally, but Cursor's context-awareness makes it more useful for real projects. Copilot is good for single-file work. Cursor is better when you need the model to understand the whole codebase.

Is Claude better than GPT-4 for development?

For the work we do, yes — mainly because of long context, instruction-following, and explanation quality. We use whichever model is best for the task. There's no religion here.

Should I use TypeScript strict mode?

Yes. Always. The overhead at the start saves debugging time later. AI is also better at generating correct TypeScript when types are strict — it has more to work with.

How do you handle database migrations?

With Supabase: SQL migration files, version controlled, applied via the Supabase CLI. We write the migration manually or with AI assistance, review it, run it in preview, then production. Never run raw SQL on production without reviewing it first.