AI-Augmented Engineering
Next.js
Claude
Case Study
DevOps
Vercel
TypeScript

I Built My Entire Professional Site in One Session Using Claude — Here's Every Skill It Required

A transparent breakdown of how I used Claude to build js17.dev from scratch: the stack, the architecture decisions, the failures, the fixes, and why the human side of AI-augmented engineering is the hardest part.

March 4, 202611 min read·

There is a widespread misconception about AI-augmented development: that the AI does the work and the human watches.

This post is a direct refutation of that idea — documented in real time.

On March 4, 2026, I opened a Claude Code session with a blank repository, a single PDF file, and a six-phase implementation plan I had written myself. Under four hours later, node scripts/verify-site.mjs https://js17.dev printed 84 passed, 0 failed, 0 warnings.

What happened in between is what I want to walk you through — not to impress you with the AI, but to show you precisely what the human brought to that collaboration that made the difference between a generic boilerplate and a production-grade professional site.


The Numbers at a Glance

⏱️
3h 58m
Blank repo → live production
84 / 84
Automated checks passing
🔄
23
Meaningful iterations
🔒
0
Secrets exposed in code

The Brief

The goal: build js17.dev — a personal professional site for a Senior AI-Augmented Fullstack Systems Engineer — from an empty directory to a DNS-verified, SSL-secured, fully tested production deployment.

Hard constraints I set from the start:

  • ✦ Vercel free tier only
  • ✦ No external CMS — MDX files in the repo
  • ✦ No static OG images — dynamic generation via Next.js ImageResponse
  • ✦ Emails via Resend, not a third-party form service
  • ✦ Cal.com embed for scheduling, with Google Calendar sync
  • ✦ 84 automated checks across 9 test suites before declaring success

🧱 The Stack

Every technology choice was deliberate, not default.

FrameworkNext.js 14 App Router

SSG/ISR per route, Edge runtime for OG images, file-based routing without workarounds.

🔷
LanguageTypeScript (strict)

Type safety across API contracts, form schemas, and GitHub API responses.

🎨
StylingTailwind CSS + CSS vars

Token-based dark/light theming without a CSS-in-JS runtime cost.

🧩
UI PrimitivesCustom shadcn-style

No CLI-generated component tree — full control, zero hidden abstraction.

AnimationsFramer Motion

useInView scroll-reveal with no layout shift on initial load.

📊
ChartsRecharts

GitHub language donut — lightweight and SSR-compatible.

📝
BlogMDX + next-mdx-remote@6

Zero database. Full Markdown + React component support in posts.

🎯
Syntax Highlightrehype-pretty-code

Shiki-powered token-level highlighting — accurate on every language.

📋
FormsReact Hook Form + Zod

Same Zod schema shared between the client form and the API route.

📧
EmailResend

Programmatic dual-email (notification + client confirmation) with domain verification.

📅
SchedulingCal.com inline embed

Native dark-theme embed with Google Calendar sync built-in.

🐙
GitHub StatsREST API + GraphQL

ISR revalidation at 3600s. GraphQL for the contribution heatmap.

🖼️
OG ImagesNext.js ImageResponse

Per-route dynamic images at Edge — no separate image service needed.

🚀
DeploymentVercel

Git-push deploys, serverless functions, automatic SSL provisioning.

☁️
DNSCloudflare (API-managed)

Programmatic record updates via REST API. DNS-only mode for Vercel SSL.

🧪
VerificationNode.js ESM script

84 checks across 9 route suites. process.exit(1) on any failure.


🧠 What I Brought to the Session

Let me be direct: the AI wrote the code. I directed everything that the code needed to be.

1. The Architecture Document

Before writing a single prompt, I produced a six-phase implementation plan covering framework selection with justification, file structure down to individual component names, render strategy per route (SSG, ISR, CSR, Edge), environment variable schema, performance targets, and verification criteria.

This is not a task you can delegate to an AI. Producing this document requires knowing what a production Next.js App Router project looks like at scale, understanding the tradeoffs between MDX solutions, knowing why next-mdx-remote@6 behaves differently from @next/mdx, and having opinions about component architecture before any code exists.

💡

Skills required: Systems architecture, Next.js internals, performance engineering, product thinking. The plan document eliminated 80% of potential ambiguity iterations before they could occur.

2. Technology Triage Under Constraints

Several decisions involved choosing between options with non-obvious tradeoffs:

  • MDX: @next/mdx vs next-mdx-remote vs contentlayer — chose next-mdx-remote for the compileMDX RSC API
  • OG Images: Static PNG vs ImageResponse Edge function — chose dynamic, one file handles all posts
  • Email: SendGrid vs Resend vs Postmark — chose Resend for Next.js-native SDK and free tier
  • Scheduling: Calendly vs Cal.com — chose Cal.com for inline embed and native calendar sync

3. Security Discipline That Didn't Bend

API keys were provided at the right moment and never written to files. When Vercel's build pipeline surfaced CVE-2026-0969 in next-mdx-remote@4, I immediately recognized what a CVE flag means in a CI/CD pipeline and directed the upgrade to v6 rather than ignoring the warning.

⚠️

Zero tolerance rule: every secret lives only in Vercel environment variables. .gitignore was verified. No credential ever touched a file. This discipline is non-negotiable at production.

4. Precise Information at the Right Moment

Every external service required exact credentials provided at the right step — GitHub PAT with public_repo scope, Resend API key, Cal.com username (jeroham-sanchez-gfvgbp), Cloudflare API token with the right permission scope. The quality and precision of this information directly determined whether each integration worked on the first attempt or required a rework cycle.

5. Infrastructure Diagnosis Nobody Can Outsource

When https://js17.dev returned HTTP 200 but served the wrong content, I diagnosed three simultaneous issues: two stale GoDaddy A records competing with the Vercel record, Cloudflare proxy (orange cloud) intercepting TLS and breaking Vercel's SSL provisioning, and the SSL certificate not auto-provisioning after DNS migration.

# The three-step fix:
# 1. Delete competing A records via Cloudflare API
# 2. Set proxied: false on A + CNAME records
# 3. Manually trigger cert issuance
vercel certs issue js17.dev www.js17.dev

This requires knowing how Cloudflare's proxy layer interacts with origin SSL — not something you can Google your way to under time pressure.


🔥 The Challenges

OG Image — Edge Runtime vs Node.js

The blog [slug]/opengraph-image.tsx initially imported @/lib/mdx to read the post title. This worked in development but failed at build: @vercel/og runs in a V8 isolate, not a Node.js process — no fs or path.

The fix required understanding why the constraint exists, then designing around it entirely: derive the post title from the URL slug parameter, never touching the file system.

// Derive title from slug — zero Node.js APIs, works in Edge runtime
const slugTitle = params.slug
  .split("-")
  .map(w => w.charAt(0).toUpperCase() + w.slice(1))
  .join(" ")

CVE-2026-0969 Blocking Production Deploy

Vercel's build pipeline flagged a critical vulnerability in next-mdx-remote@4 and refused to deploy. Upgrading to v6 required knowing that the compileMDX API from next-mdx-remote/rsc remained compatible — not a guaranteed assumption when jumping major versions of any library.

Resend Build-Time Initialization

The Resend client instantiated at module level throws during next build because Next.js evaluates API route modules before environment variables are injected. The fix: lazy initialization — instantiate only on first request, never at import time.

let _resend: Resend | null = null
export function getResend(): Resend {
  if (!_resend) _resend = new Resend(process.env.RESEND_API_KEY!)
  return _resend
}

Vercel Deployment Protection (401 on Preview URLs)

The verification script returned 401 on all routes against the preview URL. Recognizing that Vercel's deployment protection applies to preview deployments by default — and that the stable project alias bypasses it — allowed the full 84-check suite to run before the canonical domain was live.

Three-Way DNS Conflict

A GoDaddy-to-Cloudflare migration left two legacy A records (13.248.243.5, 76.223.105.230) competing with the new Vercel record, while Cloudflare proxy-on was intercepting TLS. Three API calls resolved all three issues simultaneously.


📊 Iterations vs. Information Quality

The entire build required 23 meaningful iterations. Here's the breakdown:

TypeScript / ESLint fixes iterations

Resolved by: Compiler errors — mostly mechanical one-liners

Infrastructure (DNS, SSL) iterations

Resolved by: Domain expertise + Cloudflare API access

External service setup iterations

Resolved by: Credentials provided precisely on first request

Architecture decisions iterations

Resolved by: Plan document eliminated these before they arose

CVE / security iterations

Resolved by: Immediate recognition → upgrade directive

Verification & QA iterations

Resolved by: 84-check script defined upfront as the success gate

ℹ️

The ratio that mattered: every time a precise, complete input was provided, the output required zero rework. Every time an input was ambiguous or incomplete, at least one rework cycle followed. The human's information quality was the primary predictor of velocity.


⏱️ Timeline: First Prompt → Confirmed Production

0:00First prompt — 6-phase architecture plan handed off
1:15All pages building locally, no TypeScript errors
1:45GitHub repo created, first Vercel deploy triggered
2:10CVE fix applied (next-mdx-remote v4→v6), redeploy successful
2:35Cal.com inline embed integrated (username provided, step 5 updated)
3:40Cloudflare DNS updated via API, SSL certificate provisioned
3:5884/84 checks passing on https://js17.dev ✅

For reference: this site includes a multi-step proposal form with Zod validation and dual-email submission, a GitHub stats dashboard with REST + GraphQL data and a custom SVG contribution heatmap, an MDX blog with syntax highlighting and per-post dynamic OG images, full dark/light theming, structured data (JSON-LD), sitemap, robots.txt, security headers, and a /cv redirect to a downloadable PDF.

A traditional agency would quote 3–6 weeks and $15,000–$40,000 for comparable scope.


🛠️ The Full Skills Inventory

⚙️

Engineering & Architecture

☁️

DevOps & Infrastructure

🔒

Security

🎯

Product & Design

🧪

QA & Tooling

🤖

AI-Augmented Engineering


What AI-Augmented Engineering Actually Means

This project is a working definition of the term.

It is not "AI writes code, human reviews it." That is AI-assisted copy-paste, and it produces exactly the quality you would expect.

AI-augmented engineering is the human operating as architect, decision-maker, quality gate, and infrastructure owner — using AI as a force multiplier that eliminates the gap between design and implementation.

The multiplier only works when the human brings a sound architecture, correct technology choices, security discipline that doesn't erode under time pressure, domain knowledge for the layers AI cannot access (DNS panels, API dashboards, production credentials), and a verification standard rigorous enough to catch the gap between "it looks like it works" and "84 checks pass against the live production URL."

Remove any one of those, and the multiplier disappears.


Want This For Your Project?

Ready to build something that actually ships?

Everything described in this post is what I bring to every engagement — not as a template, but as a methodology. The site you're reading was built in under 4 hours. That's not a claim about AI. It's a claim about what happens when senior engineering judgment operates at full capacity.

What you get: 🚀 3–5× faster delivery — without cutting corners on architecture, types, or tests 🔒 Production-ready from day one — security, monitoring, and deployment pipelines included 🤖 AI systems that actually work — RAG architectures and LLM integrations built by someone who uses these tools daily 📖 Clean handoffs — every system is documented, typed, and maintainable without me 💬 Transparent process — you see every decision, tradeoff, and line of reasoning

Request a Proposal →

The form takes 5 minutes. Most clients have a clear path forward within 24 hours.