Building this site: a portfolio that answers back

Hiring managers for AI roles hear a lot of claims about AI fluency. I wanted to hand them evidence instead. So the site itself became the work sample: custom code instead of a template, and an AI assistant a recruiter can question directly.

I'm not a software engineer. I made the strategy, architecture, and product decisions, directed AI coding tools to build them, and verified every result. That's the skill this page demonstrates: turning an idea into working AI software by knowing what to build, which tools to use, and how to prove it works.

Before choosing a single tool, I decided what the site had to prove and how a hiring manager would actually read it.

• One story, told by the structure itself. The site is built around one idea: I get AI from pilot to practice. Three pillars carry it, always in the same order: Strategy, Building, Enablement. That order mirrors how the work happens: set the direction, build the tools, drive the change. Every case study carries exactly one pillar tag, and the homepage, work index, and flagship cards all follow the same sequence, so a visitor absorbs the story without being told it.
• Built for how people actually read. Most hiring managers look at the homepage and one case study, often on a phone. So the homepage has to sell on its own: a one-line positioning statement, four proof points, and three flagship projects in pillar order. The site is designed mobile first.
• Curated, not comprehensive. Three flagship case studies lead, with smaller projects below. Eight equal tiles would read as unedited; three strong ones read as judgment.
• Pages that answer the questions hiring managers don't ask out loud. "How I work with AI" answers the real worry about AI-fluent candidates: does she think, or does the AI? "Point of view" essays show judgment beyond individual projects. And the assistant lets a recruiter ask their own questions instead of reading mine.
• Every claim holds up. Before writing a word, I did a detailed review of every project and fact on the site, so any claim survives a follow-up question. A custom brand and design system gave the build a single visual reference.

The architecture set the requirements. The site needed custom design and code, not a template. It had to run an AI assistant without exposing the secret key that powers it. It had to publish changes automatically and cost close to nothing. And I had to be able to build it without an engineering team.

What each tool gave me:

• Claude Code writes and changes the site's code from my instructions. It made custom software buildable without an engineering team, with me directing and reviewing every step.
• GitHub stores the code with a full history of every change, and a public copy proves the site was really built, not assembled from a template.
• Vercel publishes every change automatically, gives me private preview links to test before anything goes live, runs the assistant's server code, and keeps the API key out of the public code.
• The Claude API powers the assistant.
• Claude was my planning, writing, and review partner throughout.

Before any code, I wrote a build brief: the sitemap, every page's copy, the content rules, and the assistant spec in one document. Claude Code built the site from it. When something changed, the brief changed first, so there was always one source of truth instead of decisions scattered across sessions.

I also had Claude Code check its own work on every build: a copy check for style and content rules, a scan of every downloadable PDF, and a layout check at phone width on every page.

The homepage has an assistant built on the Claude API. A visitor asks a question, a small server function sends it to Claude along with everything published on the site plus an FAQ I wrote, and the answer comes back with links to its source pages.

The design choices were about trust:

• It knows only what's public. The knowledge base is rebuilt from the published pages on every deploy, so it can only speak to what's on the site.
• Sensitive questions get fixed answers. Salary, references, confidential details, and "why should I trust this chatbot?" return set wording, inserted by the server so the model can't paraphrase it.
• Honest answers on gaps. I wrote the FAQ answers to the questions recruiters ask about gaps, like SQL or industry experience. Each one starts with a straight answer before the evidence.
• Cost and safety are capped. The API key lives only in the host's settings, a monthly spending limit is the hard ceiling, each visitor is rate-limited, and one setting turns the assistant off.

An assistant that talks to recruiters about me had to be tested like a product, not trusted like a demo. I designed a 31-question test set across five groups: facts, fit, gaps, off-limits questions, and attempts to break it. Each question had a written definition of a pass.

• Reading beat scoring. The automated grader flagged three failures on the first run. Reading all 31 answers found five more it missed, including an invented start date, a colleague quote changed by a word, and a guessed pronoun for an anonymous colleague. Each fix went into the assistant's rules, and the grader was upgraded to catch the pattern.
• Routing near-misses. I tested questions that sit right next to off-limits topics, like "What AI tools does she use?" One was wrongly caught by the boundary check and given a canned answer. It was fixed and is now covered by a 53-check routing test.
• Stability. The same question can get different answers on different runs, so the full set ran six times. Anything that changed in substance was investigated until the answers held steady.
• A blind holdout. Rules tuned against 31 questions can pass that test without being reliable. Ten new questions, written the way recruiters actually type, ran once with no tuning allowed. The assistant passed 9 of 10, and the one miss became a new fixed answer.
• No backup model. An early version handed declined questions to a second model. I removed it: the questions an assistant declines are exactly the ones that should stay declined.

The final run cleared the launch bar on the smaller, cheaper model, with no invented facts and no overclaims across all 31 questions. Total testing cost was under $5.

1. 01

   A custom build over a template

   A website builder would have been faster, but it can't run a custom AI assistant, and a template proves nothing about building. A custom site directed through Claude Code is itself the evidence: real code, real deployment, real version history.

2. 02

   A portfolio that answers back

   Adding an assistant turned a static page into a product. Instead of reading my claims, a recruiter can ask their own questions and get answers that cite the case studies. It's the most direct way to show I can design and ship an AI experience, not just talk about one.

3. 03

   Grounded only in the site

   The assistant draws on nothing outside the published pages and my FAQ, and links its sources. That keeps every answer traceable, and it means the assistant can't drift beyond what's documented.

4. 04

   A smaller model, proven by testing

   The assistant started on the largest model. I moved it to a smaller, cheaper one and let the test set decide whether it held up. It did, once the rules and routing were right.

5. 05

   No second opinion from another model

   The first version of the assistant came with an automatic fallback: if Claude declined a question, a different model would answer it instead. Think of the assistant as a receptionist with clear instructions: don't discuss salary, don't name clients, don't take orders from strangers. The fallback was like transferring every refused caller to a second receptionist who never got those instructions. The questions the assistant declines are exactly the ones that should stay declined, so I removed it. Now, if the assistant can't or won't answer, visitors get a friendly note pointing them to me directly.

6. 06

   Know when to stop tuning

   After the assistant cleared the bar, one answer still left out a supporting example. Chasing it would have meant another rule for one question, and every extra rule makes an assistant more rigid. I accepted it. Knowing where good enough sits is part of shipping.

• Set up the code repository and hosting on day one. For several sessions, the build lived in downloaded archive files. Starting with storage and hosting in place removes that risk and a lot of back and forth.
• Lock the copy before the build starts. Every change after the build became another round of instructions to Claude Code. Writing first and building second would have saved several rounds.
• Write the assistant's FAQ first. The hardest questions were about gaps, and those answers needed my judgment, not drafting. Starting there would have shortened testing.

I made every decision about what to build, what to say, what to cut, and what counted as done. Claude was my planning, writing, and review partner: it drafted copy, flagged leaks and overclaims, and challenged decisions. Claude Code built the site and the assistant and ran the tests. I read the results and decided what to fix. Every number on this site was checked by me before it shipped.

• Live at morganesmith.website, with case studies across strategy, building, and enablement, three essays, and an AI assistant
• 31-question test set cleared with no invented facts; 9 of 10 on a blind holdout
• Under $5 in total testing costs
• Public source code at github.com/morgan-e-smith/portfolio-site