Quickstart

Launch fast

The realistic path from buying this boilerplate to a live, deployed app: clone it, install, run the init command, set what init left for you, add payment keys if you are charging for something, then deploy. Every step below is the actual command, not a simplified version of it.

The quick path

Clone and install

Clone the repo under a new name and install dependencies. npm install also works if you are not on pnpm.

Terminal

$
gitclone <your-repo-url> my-site
$
cdmy-site
$
pnpminstall

Make it yours in one command

pnpm run init asks seven questions: project name, naked domain, one-line description, who it is for, the primary goal or call to action, voice and tone notes, and an accent hex. It writes the answers to ai_rules/app_approach/app-context.md and sets the matching fields in src/config.ts. It checks every skill symlink first and stops on a broken one, so a bad clone is caught before it writes anything.

Terminal

$
pnpmrun init
# or, without the questions
$
pnpmrun init --non-interactive --name="Acme" --domain=acme.com

Safe to re-run

Running it twice changes nothing the second time. --dry-run prints the plan without writing. It does not touch Stripe, AWS or auth, and it does not write your brief or your PRD. Those come from the workflow.

Run it with zero configuration

Every integration is env-gated, so the app boots with no .env file at all. Start here before touching any keys.

Terminal

$
pnpmdev

Set what init left for you

Init already set appName, appDescription, domainName, the Resend addresses and colors.main in src/config.ts. The rest is yours: the pricing plans, and the color tokens in src/app/globals.css. See Configuration for the full token list.

Add payment keys, if you are charging for something

Copy .env.example to .env.local and fill in only the Stripe keys. ButtonCheckout and the checkout API route pick them up automatically, the webhook grants access once payment clears.

.env.local

STRIPE_SECRET_KEY=
STRIPE_WEBHOOK_SECRET=
NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=

Everything else stays optional

Supabase, Resend, Crisp, and GA4 keys follow the same pattern in .env.example. Add a key only when you need that feature; leave it blank and the feature disables itself instead of crashing the build.

Build, push, deploy

Confirm the production build locally, then push and import into Vercel. The full walkthrough, including custom domains, is on the deployment page.

Terminal

$
pnpmbuild
$
gitadd .
$
gitcommit -m "Initial commit"
$
gitpush origin main

Why the setup exists

Two things make this boilerplate faster to build on than a blank Next.js app: a rule pack that keeps your AI coding tool grounded in what actually exists in the codebase, and an architecture built to hold up as the project grows.

An AI-ready structure, so it does not hallucinate

The repo ships CLAUDE.md at the root plus a full rule pack in ai_rules/: enforceable rules (Next.js, SEO, design, performance, dashboard architecture), generators, decision records, and a context map, read by Claude Code before it acts. It also ships AGENTS.md, RULES.md, and .cursorrules for other agents and editors. The point is not documentation for its own sake: ai_rules/rules/context_management.md runs a 7-point anti-hallucination checklist before any code gets written, and AGENTS.md states the hard constraint plainly: never invent an import, function, type, or component, confirm it exists first.

This is what makes AI-assisted edits safe

Without a rule pack, an AI coding tool guesses at file paths and component names from training data and quietly breaks the build. Point it at CLAUDE.md and ai_rules/ first and it grounds every change in what is actually in your repo.

A code architecture that scales

Server Components by default. Interactivity is pushed into small, marked "use client" leaf components, not whole pages.
Typed, env-gated APIs. Every page calls getSEOTags() for metadata, and integrations like Supabase expose a config check that returns null when unconfigured, so callers fail soft instead of crashing.
One component kit, not one-off pages. Dashboard, call-to-action, typography, effects, blog, and core-shell pieces are built once and reused everywhere. See the component gallery for the full inventory.

Our open-source design system

The tokens, hairline structure, and component rules behind every piece in the component gallery are not private. They ship as an open-source Claude Code skill that front-loads design tokens and rules so an AI coding tool can only produce on-brand UI, then verifies what it built against those same rules. Read it to see exactly how the system decides what a button, a card, or a heading is allowed to look like, before you ever touch the code.

← Configuration Deploy to Vercel →