Vibe coding — describing what you want and letting an AI agent write the code — had a credibility problem among experienced developers, and for good reason: for years, a skilled engineer could genuinely write better code, design cleaner systems, and make more thoughtful architectural decisions alone. That calculus has shifted. AI agents improved dramatically, and the surrounding machinery — MCP servers, agent skills, plan-first execution, and long-horizon coding tools — turned vibe coding from a gimmick into a practical way to build real systems.
Developers now use tools like Claude Code and OpenCode to build applications once considered too complex for rapid iteration: payment platforms, wallet applications, reading apps, and full-stack production web systems. The surprise is not just the speed but the consistency of results once the right structure is in place. And that points at the real obstacle most people hit with vibe coding: it is not writing the code — it is choosing the stack. This guide, adapted from a walkthrough on KDnuggets, lays out a proven stack and a staged build order that AI agents handle exceptionally well.
The Stack
- Next.js (App Router) — frontend and layout
- shadcn/ui — UI components
- Server Actions + Route Handlers — backend logic and webhooks
- Supabase — database, authentication, storage
- Resend — transactional email
- Stripe — payments and subscriptions
- Vercel — deployment and previews
The stack is intentionally simple, and every service on the list has a usable free tier — a full application can be deployed on Vercel and connected to managed services with no upfront cost, which makes it ideal for a first project or a startup experiment.
Why This Stack Grows Without Getting Messy
As an app expands, two Next.js primitives do most of the heavy lifting. Server Actions handle form submissions and server-side mutations, keeping data logic close to the UI and eliminating boilerplate API plumbing. Route Handlers cover everything that must be a real HTTP endpoint — above all, webhooks from services like Stripe. Supabase supplies the production-grade foundations (Postgres, auth, storage) that AI agents integrate cleanly because the patterns are well documented and consistent.
The Build Order That Works With AI Agents
Step 1: MVP Foundation
Create a full product loop with minimal scope: a Next.js App Router project deployed to Vercel; a dashboard shell and navigation built with shadcn/ui; authentication flows (signup, login, reset) on Supabase Auth; one main user-owned table in Supabase Postgres; CRUD screens powered by Server Actions; and preview deployments on every change. At the end of this stage a usable app is already running in production, however small the feature set.
Step 2: Data Security and Access Control
Lock down user data before adding features: enable row-level security on user-owned tables, define read and write policies based on ownership, standardize on patterns like owner_id, created_at, and updated_at, and validate access rules through the actual UI flows rather than SQL alone. Doing this early prevents painful rewrites and keeps security aligned with how the app really behaves.
Step 3: Email and Storage
Add the pieces that make a product feel complete: transactional email through Resend for signup confirmations and notifications, file uploads into Supabase Storage with metadata in the database, and signed URLs or identity-based access control for private files.
Step 4: Billing and Entitlements
Convert usage into revenue: create Stripe Checkout sessions and redirect users; handle Stripe webhooks in Next.js Route Handlers; store subscription or purchase status in Supabase; gate premium features on stored entitlements; and deduplicate webhook handling using processed event IDs. By the end of this phase, the result is a paid MVP that can scale without changing the core architecture.
A Claude Code Starter Prompt
The following prompt — written for a “Bookstore + Reader MVP,” but reusable for any idea — drives the whole build:
Build a **Book Shop + Reader MVP** using this stack:
- Next.js App Router
- shadcn/ui
- Supabase (Postgres, Auth, Storage)
- Resend
- Stripe (Checkout + webhooks)
- Vercel
## Goal
Ship a production-ready Book Shop and Reader with paid access.
## Build
- Public pages: landing, pricing, book list
- Auth: sign up, sign in, reset password
- Protected app: reader dashboard
## Data
- `books`, `chapters`
- Row Level Security so users access only their own data
## Features
- CRUD via Server Actions
- Reader view with progress tracking
- Private storage for book assets
- Welcome email
- Stripe Checkout + webhook-based entitlements
## Output
- Clean app structure
- Minimal dependencies
- README with setup, env vars, migrations, Stripe, and Vercel steps
- Manual verification checklist per featureThe workflow: switch Claude Code into Plan Mode, paste the prompt, and adjust the idea or scope as needed. The agent plans the system first, then builds step by step — and along the way it guides the setup of required services, account creation on third-party platforms, and API key generation. The distance from idea to working application stops being a matter of setup and decisions.
Optional Tooling for Later
None of the following is needed to ship a first version, but each helps test, monitor, and harden an application as real usage grows:
| Social class | equipment options | what does it help | when to add it |
|---|---|---|---|
| unit test | wittest | Fast testing for utilities and server logic | Once core CRUD works |
| component testing | react test library | Catch UI regression in forms and statuses | After the dashboard is stable |
| end-to-end testing | playwright | Complete user flow: Signup → Create → Pay | Before adding more features |
| tracking error | guard | Pile up marks, release health, alert | As soon as real users arrive |
| logs | Axiom or Logtail | Searchable request logs, webhook debugging | When webhooks and billing go live |
| performance check | lighthouse (ci) | Catch slow pages and larger bundles | Before marketing launch |
| Schema and migration | Drizzle Kit or SQL Migration | Repeatable schema changes | As soon as you have 2+ tables |
| background jobs | ingest or trigger.dev | Async tasks: email, export, cleanup | When workflow expands beyond requests |
| rate limiting | Upstash Redis (or similar) | Protect auth endpoints and webhooks | When traffic gets real |
| product analysis | Posthog (or similar) | Funnels, Activation, Feature Usage | Knowing What You Measure |
Limitations and What to Watch
Agent-built applications inherit the weaknesses of their supervision. Security-sensitive code — auth flows, RLS policies, webhook verification — deserves careful human review even when generated flawlessly on the surface, and payment integrations should be tested against Stripe’s test-mode edge cases (refunds, disputes, failed renewals) before launch. Free tiers are genuinely free but come with limits and occasional cold starts, so growing products should budget for the paid tiers early. Stack fashion also moves fast; the specific tools here are current best-of-breed, but the underlying pattern — one framework, one managed database with row-level security, one payments provider, plan-first agent workflows — is the durable lesson. For getting more out of the agent itself, see this related guide to Claude Code power tips.
Final Thoughts
Modern development tooling increasingly assumes AI integration — good documentation, clean APIs, MCP-style access — so agents can work with services directly and build software faster than ever. For a data scientist who has never touched web development, or a newcomer who wants to launch something real, this stack requires minimal setup and delivers a deployable application almost immediately — with a clear, staged path from first commit to paying customers.
