How I ship a production site in 5 days flat

The full playbook — stack, process, AI tooling, gates, indexing, post-launch. The repeatable recipe behind 16 production sites operated by one engineer.

I ship a production marketing site from brief to live in 3–5 business days. Daily previews. Lighthouse 95+ across all categories on first deploy. Schema validates. Indexed by Google within hours of launch. This piece is the full playbook — every layer of how it works, written so you can copy it.

If you came here from a search for "ship fast Next.js" or "Claude Code workflow" or "AI-assisted developer," this is the long-form version of the answer.

The thesis: speed is a quality issue, not a tradeoff

The common framing is "fast or good, pick one." That is wrong for marketing sites. Speed is downstream of having the right stack, the right process, and the right tooling. A team that ships in twelve weeks is usually not making a more careful site — they are making a sloppier site, more slowly, because they are bottlenecked on coordination instead of substance.

The corollary: if you compress the cycle without changing the stack, process, or tooling, you ship something worse. Compressing alone is just rushing. The stack and the process are the lever.

Layer 1: the opinionated stack

Every site I ship uses the same primitives. There is no "let me research the right stack for this client" phase — the answer is already determined. This is not laziness; it is leverage. Every decision the stack makes for me is a decision I do not have to spend brain cycles on per project.

Framework: Next.js 16 App Router with Turbopack. Static SSG by default; no dynamic = "force-dynamic" anywhere.
Styling: Tailwind CSS 4 with CSS-first @theme block in globals.css. Design tokens are CSS variables, easy to swap per site.
Language: TypeScript strict. No any. Zod v4 at every validation boundary so a typo in content fails the build, not production.
Hosting: Vercel. Shape B per-site repo pattern. Orphan-branch production lock means git push makes previews, manual promotion makes prod.
Content: static TS modules by default; Sanity CMS only when an owner needs to edit posts or events without engineer involvement.
UI primitives: shadcn-style with Base UI under the hood. CVA for variants, cn() for class merging. No animation runtimes — framer-motion is on my perf-budget deny-list.

The stack is the slowest part to change and the easiest part to standardize. Lock it in once. Reap dividends forever.

Layer 2: the six-step process

Every site goes through six steps in the same order. The steps and durations have stabilized through about 20 site builds — they are not aspirational, they are what actually happens.

### Step 1 — Discovery (30 minutes)

A short call. Who is the audience? What is the value prop? What integrations are needed? What is the deadline? Structured intake form so nothing is forgotten. Notes shared back within 24 hours with a go/no-go recommendation.

### Step 2 — Brief (1 day)

A structured markdown brief — kind (marketing, app, directory), pages, palette, copy direction, performance targets. Signed off before any code is written. This is the document we refer back to throughout the build.

### Step 3 — Plan (1 day)

A numbered implementation plan with steps, expected tool calls, gate criteria, and a rollback strategy. The plan locks in the architecture — layout, content structure, schema strategy, hosting topology. Mid-run changes require a re-plan, which makes the client think twice before scope-creeping.

### Step 4 — Build (2–3 days)

Iterative ship cycle. Daily previews on a Vercel URL. AI tooling does the scaffolding and refactoring; I review every change. The build is structured so the client sees progress every morning, not at the end. By end of day 4 there should be a clickable thing you would happily put your name on.

### Step 5 — Audit (1 day)

Hard gates before launch. Lighthouse on every page. Schema.org validation via Google Rich Results Test. Content review against the AI Overview citation checklist. Design review with screenshots. Below 95 on any Lighthouse category equals blocker. No exceptions.

### Step 6 — Ship and monitor (1 day plus 30 days)

Production deploy. Domain pointed, DNS verified, SSL active. Sitemap submitted to Search Console. IndexNow plus Google Indexing API ping every URL. 30 days of post-launch monitoring — weekly Lighthouse, Search Console coverage check, content tweaks as requested.

Layer 3: AI tooling as a force multiplier

Claude Code is the central nervous system. Not because it writes the best code — it does not always. Because it removes the friction between intent and action. I describe a change in English; the right files get edited; tests run; commits land. The human-in-the-loop is on the decisions that matter — architecture, content tone, schema choices — not on the mechanical work of typing imports and formatting and scaffolding.

### Custom MCP servers for stack integration

Each service in my stack has an MCP server: Cloudflare for DNS and zones, Sanity for CMS schema, Vercel for deploys, GitHub for PR ops, Firecrawl for scraping, Playwright for browser testing, Sharp for image processing, plus my own factory-router for cost-aware model routing and a local RAG MCP for codebase memory. Claude Code orchestrates them; I describe what I want at a high level and the MCPs do the API calls.

### Cross-model code review

For high-stakes changes — architecture, AI prompts, anything pricing-affecting — I run a two-model review. Codex CLI does a first pass, Claude critiques the Codex draft adversarially. Two different model architectures catch different bugs. The cost is about fifty cents per review. The value is catching the issues that single-model reviews miss.

``bash # Cross-model review of a PR diff git diff main..HEAD > /tmp/diff.patch codex --review /tmp/diff.patch > runs/codex-pass.md # Claude then reviews codex-pass.md against the original diff # Blockers from either model = stop and fix``

### What AI tooling is NOT

AI tooling is not autopilot. Every architectural decision is mine. Every content tone choice is mine. Every "ship vs hold" call is mine. The AI removes mechanical friction; the human keeps judgment. Teams that hand judgment to the AI ship worse sites, faster — that is the wrong tradeoff.

Layer 4: the hard gates

Every site I ship passes the same six gates. Failing any one blocks the launch. The gates are not aspirational — they are non-negotiable, and they are what keeps quality from sliding as cycle time compresses.

Gate A — Design quality: 6-dimension scorecard (typography, color, hero, motion, layout, hierarchy). Each scored 1–5; composite at least 3.5 to ship.
Gate B — Routing integrity: every page renders, every link resolves, no 404s on internal navigation, no dynamic flags.
Gate C — Cost integrity: bundle size in budget, no animation runtimes, no icon libraries imported as packages.
Gate D — Scorecard pass: the run's plan got executed, no deferred work hiding under the rug.
Gate E — Lessons captured: every run produces a lessons.md so next time is better.
Gate F — Pack-specific: Lighthouse at least 95 across all categories, schema validates, accessibility WCAG-clean, content E-E-A-T-strong.

These gates exist because "good enough" creep is the default state of any project. The gates are how I stop the slide. Once the gates exist as code in the audit step, they enforce themselves — no negotiation, no "let's ship and fix it later." A page below 95 cannot reach the release step.

Layer 5: indexing as part of the build, not a follow-up

Most builders ship a site and then "do SEO." That is backwards. SEO surface — schema, semantic HTML, AI Overview citation patterns — is baked into the build from the first page. The first deploy is the one that gets indexed. Subsequent improvements should be marginal.

### Schema.org on every page

Homepage gets WebSite and Organization. Service pages get Service and Offer with provider. Service-area pages get Service and Place with AreaServed. FAQ pages get FAQPage with Question and Answer entities. Every dynamic page gets BreadcrumbList. Validated via Google Rich Results Test before launch — if a page does not validate, the page does not ship.

### AI Overview citation patterns

Every page mirrors the user query in the H1. First 60 words give a direct extractable answer. 15+ named entities per page — specific businesses, neighborhoods, services, prices. Author byline with verifiable LinkedIn link at the bottom (96% of AI Overview citations come from E-E-A-T-strong sources). Statistics with attribution. No login walls, no paywall. The pattern is repeatable. The impact is 4.4 times conversion vs traditional organic traffic.

### Autonomous indexing post-deploy

IndexNow submission to Bing, Yandex, Brave on every URL the moment the site goes live. Google Indexing API submission via service account (200/day quota per niche). An hourly cloud routine fires for every site I run, keeping new content discoverable within minutes of publication. The mechanism is documented in a separate write-up; the key idea is that indexing is infrastructure, not a manual step.

Layer 6: the long game (post-launch operations)

Shipping is not the finish line. After launch, sites need weekly Lighthouse audits to catch regressions early. Search Console monitoring for coverage issues and query trends. Schema drift checks because a content update breaks a JSON-LD field and the page silently loses its rich result. Citation tracking — which AI engines cite the site, where. Backlink monitoring for new links worth keeping and toxic ones worth disavowing. Content refresh on a cadence, because stale data equals lost ranking.

Manual ops at one site is tolerable. At sixteen sites it is impossible. The solution is autonomous routines — cloud-fired cron jobs that do the audit, write reports, alert on regressions, and only escalate when human judgment is needed. The factory works while I sleep.

What you can copy

The pieces transfer. The stack is open-source and free. The process fits on a napkin — six steps, named durations, named deliverables. The AI tooling is available to anyone with a Claude Code subscription and an OpenAI Pro account. The gates are documented. The schema patterns are linked from this site.

Start with the stack. Lock in Next.js 16 + Tailwind 4 + TypeScript strict + Zod + Vercel. Resist swapping. Every "what if I used X instead" question is a context-switch tax.
Adopt the six-step process. Use it on the next three builds. Iterate the durations to your actual data.
Install Claude Code, configure 3–5 MCP servers for your stack. Spend a week building muscle memory before judging the workflow.
Write the gates as code. Each gate that exists only in your head is a gate that will be skipped on a busy week.
Build the indexing pipeline once. Reuse on every site.
Defer to AI on mechanical work, never on judgment. Use cross-model review on anything high-stakes.

What this approach is bad at

Custom design beyond the pack conventions. The factory is fast at "well-conventioned site"; less fast at "this site looks unlike any other."
Stacks other than Next.js and Vercel. Migrating clients off WordPress is feasible; building new sites on PHP or Laravel is not in my factory shape.
Long-running app projects with deep state. Marketing sites and directories are the sweet spot; SaaS apps with complex backends are out of scope.
Onboarding another engineer. The system is dense; expect 2–3 weeks of ramp-up time. Mitigation: extensive docs in CLAUDE.md.
Teams that need consensus before any decision. The factory assumes a single decision-maker. Add stakeholders and the cycle time goes up.

The meta-lesson

The thing that makes this work is not any one piece. It is that the pieces compose. The stack makes the build predictable. The process makes the cycle compressible. The AI tooling makes the friction lower. The gates make the quality non-negotiable. Each piece independently is incremental; combined they shift the curve.

If you take one thing from this — pick a stack, pick a process, write the gates as code, and use AI tooling without giving up judgment. The first three sites will feel slow. The next ten will feel fast. By site twenty you will be operating a factory.

I'm available now for full-time, contract, and freelance roles. If you have a marketing site, niche directory, SEO audit, or factory automation work you want shipped, I reply within a day.