An AI‑Native Portfolio

A recruiter-facing portfolio surface that did three things at once, shipped in a hard timebox while interviewing several days a week. The constraint was time, not scope.

This site has a wide scope, and more is coming soon. I deliberately scoped MVP down to five pages— Landing, Resume, About, Contact, Music—with everything else I'm working on gated behind a no-public-placeholders rule. Day 4 was my deadline for a shippable MVP; Days 5 through 7 were for polish and stretch goals.

Most of the code is the agent's. Most of the decisions are mine. The interesting part—and the part recruiters keep asking about—is what that division of labor actually looks like in practice.

Most sessions started with me writing or referencing the plan (PLAN.md), the agent and I aligning on what to build, then the agent shipping a working iteration in 15 to 45 minutes. I'd review, redirect, and redline. The total build time was a fraction of what solo-coding would have taken; the cognitive load was almost entirely on direction and judgment, which is the part of the work that I specialize in (and that adds value to AI-native product teams).

The site looks deceptively simple: a recruiter cluster, a few sub-brand pages, a case-study cluster. The decisions that hold it together are quieter, and they're the part worth flagging for anyone reading the source.

The /music page was supposed to be the easiest of the sub-brand pages. The brief was straightforward: pull the public playlists from my Spotify account, render them in a grid, link to detail pages. Three plot points later, it took three times longer than estimated.

The cure was straightforward: concurrency limiter (3 in-flight max), retry-on-429 honoring Retry-After, and a graceful fallback page when Spotify is unreachable. The lesson is the part that travels: rate limits are a property of production systems, and “I'll add throttling later” is a sentence that buys you a 21-hour penalty box. Should have throttled from the first request.

There's a quieter PM lesson in here too. The original ROI estimate on the Music page assumed the API would behave the way the docs described. That assumption broke twice (deprecation, reshape) and the rate-limit was the third hit. Multi-day vendor incidents on a one-week MVP are exactly the kind of thing that should slip into the buffer, not push out the deadline. Music slid one day; the rest of the week absorbed it.

A subtler discovery after the fact: Spotify rate-limits per endpoint family, not per app. A clear /me bucket doesn't mean a clear /me/playlists bucket. I built a small probe (npm run spotify:health, also exposed at /api/spotify/health in dev) that hits both and returns the time-to-clear. When /music misbehaves now, the diagnostic is one command away—instead of a 21-hour mystery box.

Pair-programming with an agent looks deceptively like pair-programming with a person—until the agent has been wrong twice. A human collaborator who's been wrong twice will usually abandon the hypothesis class and try something fundamentally different. The agent generates refined variations of the same hypothesis as long as you let it. This build earned three of those loops, each with a bigger blast radius than the last.

The first two were small. The landing-page CTA was supposed to be a solid black or white pill; it kept rendering as outlined transparent. Four rounds of debugging followed—the agent generating plausible hypotheses about CSS rules, each round a different surface-level fix that didn't change the outcome. The actual bug: a color value silently failed to resolve at the button. The browser didn't throw an error—it fell back to a default that happened to be transparent. The diagnostic that ended it: stop changing the syntax, replace the value with red, tell me if the button is red. Binary outcome, 30-second test. Catching the agent in that loop is a critical PM skill that I would argue requires some level of technical expertise ↗.

As I duplicated the Basecamp Coffee case study onto this site, the same class of bug returned. A scroll-progress bar—conceptually a 50-line change—took 15 commits and an evening. Same shape: a value failing silently, the browser falling back without complaint. The part worth sitting with: I had a written memory note from the button bug describing exactly this pattern. The memory existed. It wasn't operationalized. The 15-commit saga happened anyway. Documentation of a lesson isn't the same as discipline around it—writing the postmortem feels like resolution; carrying it into the next session isthe resolution. Almost every product org I've worked in conflates the two, and an AI-native system will pick up the same conflation if you're not careful.

The third loop earned a different magnification. Mid-audit, the local dev server stopped compiling—no error, no progress, just silence. The agent diagnosed it confidently as a Node version mismatch: specific, coherent, rhymed with prior knowledge. On the strength of that diagnosis it walked me through swapping the global default Node version on my machine. Still hung. A 90-second sanity check—does the bug reproduce in a fresh project of the same framework?—would have falsified the diagnosis before any of those changes. Same recursion shape as the first two bugs, but with a bigger blast radius: instead of iterating in code, this loop drove a real-world action against a wrong narrative. The agent constructs internally-consistent narratives faster than it falsifies them.

Three loops, three rules. They now load on every Claude session because they live in ~/.claude/memory—not because I've reread the postmortem. The difference, again, is the difference between memory and discipline. The class hasn't stopped showing up; the rules make each recurrence cheaper than the last.

One person, three reading contexts. The /resume page is built for browsing—a recruiter following a link from LinkedIn or an emailed intro. The .docx template is what I download and tailor per application, export to PDF, then submit through the company's portal—ATS-shaped, single column, no fancy typography, edited to the specific posting. And the standard PDF is a static fallback for anyone who just wants a file in their inbox without asking—no tailoring, perpetually current as the source evolves. Three jobs, three editorial decisions, one underlying record.

Three artifacts, two pipelines. The web resume sources from app/resume/resume-data.tsx (JSX-aware, since some bullets embed inline links). The .docx and the PDF both come from a single Node script chain—build-resume-docx.mjs makes the Word file; build-resume-pdf.mjs runs that and converts. So the .docx and PDF stay in lockstep automatically; the web version is the parallel maintenance burden. Bridging the JSX and the Node side would mean a TS compiler step plus a React-element walker for an artifact regenerated maybe once a month. I accepted the parallel maintenance, with a comment at the top of each file pointing at the other, since there is value to use case matching.

A handful of details worth flagging for anyone building something similar—most of them about respecting the actual reading mechanics of a Word doc that may be parsed by ATS, opened in Google Docs, exported to PDF, and printed before it gets read:

• keepNext: true on every paragraph in an entry except the last. Prevents Word from breaking a single role across pages—the rule any recruiter would tell you about a resume but no template enforces by default.
• titlePage: true to suppress the page header on page 1. Page 1 carries the full hero (name, headline, contact, summary) in the body. Pages 2+ get a minimal header so a printed-and-stapled resume still identifies itself if the pages get separated.
• Hyperlinks preserved through the .docx → Doc → PDF pipeline. Every company name, every contact item, every case-study title carries a real href. ATS that strip formatting still get the URL as text; humans clicking through the PDF in Gmail get a working link.
• Friendly link labels. “LinkedIn · GitHub · Personal Website” instead of bare URLs in the contact strip. Easier to scan, less visual noise, the underlying hyperlink still resolves.
• Company URLs match each company's actual canonical hostname. People Inc., Muck Rack, GitHub, and Calendly canonicalize to apex (no www.); LinkedIn, User Interviews, Fullstack Academy, Fractured Atlas, Artist Growth, and NEFA canonicalize to www.. Matching each site's canonical avoids a 301 redirect hop when the link is clicked. Approximately zero recruiter value, and a non-zero number of senior engineers will notice.

Pre-launch QA at solo-PM scale needs three lanes that don't overlap—one for accessibility, one for design cohesion, one for code maintainability—and a way to merge them into a single punch list. Of the five sub-agents I built, three sit on the QA loop: a11y-reviewer, design-reviewer, and code-reviewer. Growth and SEO sit outside it; they operate on different surfaces and a different cadence. The three on the loop run as a single orchestrated command.

Each role spec lives at ~/.claude/agents/<name>.md: checklist, output format, severity definitions, and an explicit what NOT to do section so the agents don't drift into each other's lanes. All three were standardized on a shared severity vocabulary—Critical, High, Medium, Low, plus a Couldn't-verify bucket—so a downstream orchestrator can merge their reports cleanly.

I built a custom command, /full-review, that ties them together. It establishes scope (current diff, or whatever the user named in the previous message), spawns all three reviewers in parallel, then synthesizes their reports into a single structured punch list. Two sections come first: Conflicts (where reviewers disagree on the same element—the user adjudicates), and Aligned (where two or more reviewers independently flag the same issue—high-confidence calls). After that, the standard severity buckets, exhaustive—no findings cap, to explicitly surface everything reviewable rather than a curated top-N list.

The first run, against the entire site in light and dark modes, came back with ninety-nine findings. One of them—a token-chain bug that silently invalidates the recruiter cluster's text colors—was independently flagged by both the design reviewer and the a11y reviewer at Critical severity. That's the kind of cross-confirmed signal a single reviewer would have either missed entirely or underweighted. Aligned items are the highest-leverage fixes; conflicts are the ones the user actually has to think about.

Ninety-nine findings is a lot to triage from a markdown report. So the synthesis output also renders as a self- contained interactive HTML dashboard at _private/_reviews/full-review-<date>.html, with each finding as a card carrying severity, reviewer tags, file:line citation, description, and fix recommendation. Status dropdowns (Open / Done / Won't do) and severity dropdowns are wired to localStorage, so working through the list survives reloads. Filters on Status, Severity, and Reviewer cut the list to whatever slice you want to work in.

The point isn't the dashboard. The point is that the review becomes load-bearing data—something to triage, manage, and check off—instead of a markdown file that gets read once and buried. Per the recursion lesson above, written notes don't drive behavior. A working surface does.

A day after the first run, with the audit-closeout commits landed, I ran /full-review a second time on the closeout work itself. It surfaced 35 substantive new findings—six items the first pass had missed, twelve tradeoff costs of choices I'd made knowingly, and seventeen regressions in code we'd just written. Forty-nine percent of the new findings were brand-new bugs introduced while fixing other bugs.

The reflection on the missed-six was the more humbling number. Five of the six were variations on a single failure mode: we'd audited the trigger of a fix, not the family the bug belonged to. The original --text-action contrast fix landed for the components we'd noticed but missed PaginationButton (which used --primary-default directly) and --border-focus (which chained through --primary-700)—sibling bugs in the same family. A 60-second class-audit would have caught them.

Both lessons now sit in AGENTS.md at the repo root, where any agent working in the codebase reads them before writing the next fix: catch regressions during the change, not in the next audit (three failure-mode checks before declaring done—error paths for new scripts, breakpoint pass for UI, consumer grep for shared logic), and when fixing a class of bug, audit the whole class (name the abstraction, grep every consumer, verify each under the same conditions). Per the recursion lesson in Button Mashing above: written documentation isn't operational discipline. The repo-level rule is the discipline; the markdown is the documentation. Both, not one.

A new instance landed mid-redline on this very article. One visible JSX-whitespace bug in Section 8 (Three Resumes) surfaced eleven siblings—ten on this page, one on the Basecamp study—once the trigger was audited rather than patched. The rule paid for itself in a single sweep.

As of writing, the MVP is live, gated behind a Basic Auth proxy while the site is being battle tested by close friends and colleagues. Two audit cycles deep, with the regressions and class-audit lessons captured as repo-level rules so the next agent doesn't earn the same ones.

PM judgment is mostly about what not to ship. The biggest scope cut from the MVP: forthcoming sub-brand pages. No content for them yet—per the no-placeholders rule from Section 3, they appear in nav and on landing the day they ship, not before. Stay tuned...

What I'd do differently next time:

This case study is a deep dive into how this site was built. My first time using Claude to build a site is documented in another case study: Basecamp Coffee →.

If this resonated, two next steps: Review my resume → or Book a 30-min product chat ↗.