Build log8 min

Building the portfolio I'd actually want a recruiter to read.

The brief, the rejected directions, the design decisions I made on the way to a v1 (built with Claude as a pair-programmer), and the one thing I'd tell another analyst to do before designing anything.

Why this at all

I built this site for two reasons.

First: the job hunts I'd run on just a resume and a screening call kept leaving hiring managers asking "do you have anything to show?" The honest answer was "not really, no." Every BI analyst I know has a portfolio that lists past companies, tools, and bullet points. Every recruiter I talked to said the same thing after screening calls: "we'd love to see your work."

By "your work" they didn't mean a list of Tableau links. They meant: what problem did you solve, what was the before and after, and why did it matter? The standard portfolio doesn't answer those questions. It lists projects and hopes the interviewer fills in the blanks.

Second: I wanted to learn AI hands-on. Not as a topic to read about, but as a collaborative partner to build something real with. The site is both the artifact and the experiment. The writeups (find them at /work) and projects (coming soon to /writing) are the deliverables; building them alongside Claude is the meta-experiment of what it looks like when an analyst actually uses AI tools to ship.

So I built something different. This is how it went.

The brief

Two constraints shaped everything.

The audience is a Series A-C VP of Product or Growth Analytics lead, not another BI analyst. They'll spend 90 seconds on this site before deciding whether to reply to my cold email. They don't need confirmation that I know SQL - everyone applying for this kind of role knows SQL. They need to see that I've shipped something that changed a number.

I'm not primarily a developer, and pretending I am would backfire. A portfolio that looks like a developer's portfolio but was built by a BI analyst reads as over-engineered. I wanted something that said: this person leads with outcomes and isn't afraid to lean on the right tools to ship the minimum thing that makes the point.

That's the brief: outcome-first, minimum viable signal, AI-collaborative throughout.

What I tried first

Three directions before this one.

Direction 1: Template site. I looked at Notion, Framer, and a handful of portfolio templates. They're fine for frontend engineers who want a portfolio up in a day. For a BI analyst, they all have the same problem: the template assumes the work is visual. Dashboards don't screenshot well. SQL queries don't either. The templates are built for designers and engineers, not for people whose work lives inside enterprise SaaS platforms.

Direction 2: Resume PDF + LinkedIn. Simpler, yes. But the feedback from the first round of applications was consistent: a PDF is a static claim. "Returned ~1,500 hours per year to the team" is a sentence a recruiter takes on faith. A deep dive with the before/after data, the constraint that shaped the decision, and the part where it almost went sideways - that's a claim that earns some trust.

Direction 3: Build it solo, no AI. This was the version that would have taken six months and probably wouldn't have shipped. Working with Claude as a pair-programmer wasn't about skipping the thinking. It was about compressing the iteration speed. The decisions throughout were still mine. The "I tried X, what about Y, here's why I think Z" speed of working things out was where the AI partnership earned its keep.

What I landed on: a site that functions like a report. One headline metric per writeup. Every section built to answer one question a hiring manager actually asks.

The design decisions

I built this in Next.js 16 with Tailwind CSS 4 and no UI library. Claude Code was the pair-programmer for every decision below - the design choices are mine, the iteration speed wasn't. (Claude Design at claude.ai/design helped earlier, on the PRD that started the project.) The decisions that felt arbitrary at the time turned out to be load-bearing.

One accent color, full stop. The whole color scheme is a single cobalt accent on off-white (light mode default) and near-black (dark). One accent forces every element to earn its place. If something doesn't use the cobalt, it better be structural. A richer palette gives you more creative options and more opportunities to make the site look like a theme someone else designed.

The command palette. Cmd+K opens a quick-nav. I added it because the hiring managers I'm targeting are technical enough to reach for it. It also shortcuts the most important pages: the writeups list, the resume download, the schedule link. If someone is interested and impatient, it's the fastest path to what they actually want.

The writeup structure. Every project deep-dive has seven sections, in order: headline, context, decision, process, results, tradeoffs, artifacts. The tradeoffs section is non-optional. A portfolio that only shows wins reads as a brochure. The "what I'd do differently" section is where the signal actually lives. It separates someone who executed a plan from someone who learned something from it.

No contact form. I have email, a Cal.com scheduling link, and LinkedIn. A contact form adds friction for the person filling it out and a deliverability headache for me. Direct links are better.

Headshot on the homepage. The BI-to-product track I'm targeting has a culture-fit component that's heavier than most people admit. A headshot on the homepage acknowledges that the hiring manager decides in 30 seconds whether they want to talk to this person. The headshot is one data point in that decision. Burying it on an About page is false modesty.

What I'd change

Three writeups are live at /work, with more in the writing pile. I don't have a fixed release schedule for them - each one needs both the underlying work cleared for public sharing AND a brainstorm pass on the framing. The first part is slower than I expected. If I were doing the site over, I'd have drafted the framing for all the writeups in parallel with the site build, not after.

The headshot is soft. 591×586 pixels is below retina resolution at the size it displays. I'll swap it once I have a better photo.

The Spotify "recently played" widget is mocked. The plumbing is straightforward (Spotify Web API, refresh-token rotation, a 5-minute Edge cache) but I needed to ship the site before wiring the credentials. It'll be live in the next update.

The one thing

If there's one thing I'd tell another analyst before they start their portfolio:

Lead with the number, not the project.

"Salesforce case automation" is a project name. "Returned ~1,500 hours per year to the team" is an outcome. When you're applying for a role, the hiring manager is trying to answer one question: is this person likely to move a number at our company? Start with the answer to that question, then explain how you got there.

This applies everywhere - resume bullets, cover letters, cold emails, this site. The number is the lead. Everything else is context.

Bonus, for 2026: if you're building something to showcase your work, use AI as a collaborative partner. Not to write your work for you - the decisions have to be yours - but to compress the iteration speed of building the thing that holds them. The fact that I shipped this site at all is partly a function of how I worked with Claude through it. That itself is worth saying out loud.

Want to write back?

Topic suggestions, push-back, or just a thread to pull - I read everything.