Designing & Building an AI-Powered Portfolio

I designed and built my own portfolio from scratch — including a custom "chat with my portfolio" AI assistant and a server-side contact form — as living proof of an AI-augmented product designer who can design and ship.

My previous portfolio lived on a hosted builder (UXfol.io). It showcased design work but said nothing about my ability to build, or my focus on AI-augmented product design. For the AI-focused UX roles I'm targeting, I needed a portfolio that was itself evidence of the skill.

I weighed vanilla HTML + Tailwind (simplest to learn), Astro (great for a content site), and Next.js. I chose Next.js because a real AI feature needs a secure server-side environment to call an LLM without exposing keys — and React/Next is the language of the AI-product teams I'm targeting. The feature drove the stack, not the trend.

I defined the palette and type as Tailwind v4 @theme tokens — a single source of truth. Two decisions mattered: the original brand blue (#4884fa) failed WCAG AA for small text, and its brightness clashed with the muted neutrals.

So I replaced it with a desaturated slate-blue (#3E5C78). Because everything references the token, this was a one-file change that recolored the entire site — the payoff of a token system. White-on-accent contrast lands around 7:1.

As my role grew toward product management, the brand needed to grow with it — more premium and editorial, less startup-blue. So I put the token system to the test a second time: I retired the slate-blue accent and the warm sand, and moved the whole site to a lux palette — a deep charcoal rail, warm ivory surfaces, and a single champagne metallic accent.

Because every color still resolved through a Tailwind @theme token, the shift was again mostly a one-file change that cascaded everywhere — the dark glass sidebar, the nav, buttons, links, forms, and the résumé all followed. The same token discipline that recolored the site the first time paid off again, this time toward a more refined, product-leader feel. Proof that the system, not the paint, was the real deliverable.

With the palette settled, I layered in a subtle motion system so the site would feel considered rather than static: a staggered entrance on the sidebar, scroll-reveals that ease each section up as it enters the viewport, slow champagne-tinted zooms on imagery, and a champagne underline that draws in beneath links on hover.

I built it with plain CSS and a small IntersectionObserver — no animation dependency added to the stack — and every effect honors prefers-reduced-motion, disabling itself for visitors who ask for less. A single shared easing curve keeps the whole system feeling like one hand made it.

To keep the identity consistent everywhere I show up, I rebuilt my LinkedIn and X/Twitter cover images in Figma to match — the same charcoal-and-champagne palette, Mulish type, and the "Product Manager · UX · Builder" positioning line from the site. The portfolio and my social presence now read as one brand rather than three near-misses.

Reusable, data-driven components throughout: a fixed editorial sidebar; a résumé rendered from structured data (ATS-readable) with a PDF download; a rebuilt About page; Contact and Testimonials pages; and a Work index. Testimonials and Work each read from a single shared data file, so adding an entry updates every place it appears.

Rather than hand-build each case study, I designed a section-based template: each case study is structured data — an array of typed sections (hero, meta, two-column, columns, quote, stepper with jump-links, image+text, gallery, persona carousel, closing) rendered by one component. Authoring a new case study is a data file plus one registry line.

This paid off directly: I added the SSO Dashboard and In-House Proprietary CMS case studies as data files, mapping dozens of legacy screens onto the schema with no new page code. Systems thinking made visible.

As the case studies grew, I built shared UI into the engine instead of one-off markup: a gallery carousel with an optional light/dark toggle (so a product designed in both themes can be viewed either way), a full-screen lightbox for reading dense dashboard screens at real size, and a scroll-to-top control for long pages. Each lives in the case-study layer, so every study inherits it.

Every component was type-checked in isolation before it touched the repo. When a data-file edit threw a real TypeScript error, I reproduced it and confirmed the fix cleared it before shipping.

Two carousels — personas and final-UI screens — started to feel like they came from different kits. Rather than force them into one layout, I unified the chrome (same chevron, slate-blue arrows, active-dot treatment) while keeping each layout suited to its content: arrows overlaid on an image versus a control row beneath a tall persona card. Cohesion through a shared visual vocabulary, not identical structure — the principle a design system runs on.

A Resend-backed API route sends messages straight to my inbox — server-side, with input validation, a honeypot for spam, reply-to wired to the visitor, and graceful error states. A second secure backend integration alongside the AI assistant.

Case studies sit behind a lightweight password gate (Next.js proxy + a secret cookie), so I control who views them — with one case study left public as a showcase. Pages are gated; static assets pass through.

Auto-scrolling marquees and the carousel respect prefers-reduced-motion; the carousel pauses on hover and is fully keyboard-navigable with 44px targets. Semantic HTML throughout (figure/blockquote, dl/dt/dd, labeled forms); the résumé is real text for screen readers and ATS; and I checked every text/background token pair against WCAG AA contrast.

I documented the genuine friction of building on Windows as a designer new to the terminal: installing Node and Git and fixing PATH/execution-policy issues; recovering after a stray npm audit fix --force downgraded Next.js (a lesson in why node_modules is disposable); image-quality decisions (source resolution vs. display size, transparent-PNG logos); and migrating the deprecated middleware→proxy convention and tsconfig baseUrl.

Git set up from scratch and pushed to GitHub, with a deliberate check that .env.local (API keys) stays out of the repo — the foundation for continuous deployment to Vercel.