The right way to build a Next.js SaaS with an AI coding agent
You're going to build your SaaS with an AI agent anyway. Here's what makes a codebase one an agent can extend without quietly breaking it.
Most people building a SaaS today do it with an AI coding agent — Claude Code, Cursor, or similar. Yet most boilerplates were written for a human reading them top to bottom. That mismatch is where agent-built projects go sideways: the agent doesn't know the conventions, can't see the security rules, and has no way to check its own work.
Why generic boilerplates fight you
- Conventions live in the maintainer's head, not the repo — so the agent invents its own and they drift.
- Security rules are implicit. Nothing stops the agent from writing plan state from client code or leaking a service key.
- There's no verify step, so a regression only surfaces when a user hits it.
What 'agent-ready' actually means
An agent-ready codebase makes the implicit explicit. Three things do most of the work:
- Written conventions — an AGENTS.md that states the architecture and the hard rules, so the agent follows them instead of guessing.
- Security in the structure — the service-role key only reachable from the webhook; plan state only writable server-side. The layout enforces the rule, not a comment.
- A verify step — one command (typecheck + lint + build) the rules require after every change, so regressions surface immediately instead of in production.
The stack that holds up
For an AI-native SaaS you want boring, well-documented infrastructure the agent already understands: Next.js (App Router), Supabase for auth and Postgres, and Stripe for billing. The value isn't the stack — it's how it's wired.
The one rule that saves you: payments flow one way
The most common self-inflicted wound in an agent-built SaaS is trusting client-reported subscription state. Don't. Payments flow in exactly one direction: client → checkout → Stripe → signature-verified webhook → database. The webhook is the single writer of plan state. Nothing the client says about what plan a user is on is ever trusted. Bake that into the structure and an agent can't accidentally break your billing.
Verify after every change
Give the agent a rule it can't skip: run the verify script after every change, and don't call the task done if it fails. That single discipline catches the type error, the lint slip, and the broken build before they ever ship. It's the difference between an agent that helps and one that quietly accrues debt.