Problem
Most portfolios are a CMS with a theme on top, or a single page nobody can extend. I wanted the content model to be the interesting part, and I wanted authoring it to be backend practice rather than filling in a form.
Approach
Content is MDX and JSON in git, validated by one Zod schema in packages/schema. That schema
has three consumers: the ausaf CLI that authors content, the Next.js build that renders it,
and the API routes that narrow their own request bodies. A bad frontmatter field fails the
production build with the file and the field named, which is the whole reason the package
exists.
The database stays off the critical render path. Pages are static. Mongo handles the things that genuinely need writes, so a cluster outage degrades a guestbook instead of blanking the site during the twenty seconds a recruiter is looking at it.
Where the AI part is
Not in the product. The site has no chat widget and no model calls at runtime, and adding one would be a worse portfolio.
The AI is in how it gets built. The repo carries its own agent instructions and a local
humanizer skill under .claude/skills/, so prose written for the site gets checked against
a catalogue of AI writing tells before it ships. Content edits run through that pipeline.
Claude Code does the typing, the schema and the CI gate decide whether it was right.
Hard decision
Serverless plus a Mongo round-trip on the critical path would have been simpler to build and would have cost a visible amount of first paint. Cold start, then a query, then render. Every page on this site is prerendered instead, and the dynamic parts arrive after.
What's left
The CLI commands and most of the API routes. The schema they share is finished and tested, which is the part that was worth doing first.