What happens when a designer decides to build her own site from scratch, using AI as a coding partner and not a shortcut.
I've been a product designer for ten years. I've handed off hundreds of specs to engineers, written more Jira tickets than I can count, and sat through more sprint ceremonies than I'd like to admit. But until this project, I had never shipped a single line of production code on my own.
This portfolio changed that. Not because I suddenly became a developer (I didn't), but because I found a way to work alongside AI that actually felt collaborative. Less like delegating, more like pairing with someone who knew the code while I knew what I wanted it to do. That tool was Claude Code, and building this site taught me more about the gap between design and engineering than any sprint I've ever sat through.
Key Takeaways
@theme block works like a real enforced design system: define color tokens once and use them across the entire codebase68% of designers think they should know how to code, but actually doing it is a different story (CollabSoft, 2025). Here's what I knew when I started this site: HTML basics, how to read a selector, how not to be scared of inspect element. Here's what I didn't know: anything meaningful about package managers, build systems, or why Node.js was supposed to matter.
My first conversation with Claude Code was a bit awkward, honestly. I said something like: "I want to build a portfolio site. I'm a product designer. I want it to feel like me, not a template." Claude asked me a few follow-up questions about stack, hosting, animations, and I realized I had no answers to any of them yet.
The questions I couldn't answer at the start turned out to be exactly the things I needed to make decisions about. Getting them surfaced early was more useful than I expected.
We landed on Next.js with the App Router, Tailwind CSS v4, and deployment through GitHub. I had no strong opinions on any of it. I just wanted something modern that I could iterate on fast, without having to reconfigure a build system I didn't understand every time I wanted to change a font.
Only 39% of designers say cross-discipline learning is the best fix for designer-developer friction (CollabSoft, 2025). Starting this project, I understood why that number is low. The gap between "I should learn to code" and "I'm setting up a Node project from scratch" is bigger than most design think-pieces acknowledge.
63% of people using AI-assisted coding tools in 2026 are non-developers: designers, marketers, founders, according to Second Talent's 2026 vibe coding report. There's a reason the term spread so fast. It describes something real: building through intent rather than technical command.
There's a version of AI-assisted coding that's basically just copy-pasting answers from a chat window. This wasn't that. Claude Code runs in the terminal, reads your actual files, makes edits directly, and tracks what's changed. It's much closer to working with a very fast, very thorough junior dev who can also explain exactly what they just did and why.
“I stopped thinking of it as AI writing code for me and started thinking of it as me making design decisions with someone who could implement them immediately.”
The shift I noticed over the first few sessions: I stopped thinking of it as AI writing code for me and started thinking of it as me making design decisions that someone could implement right away. When I said "the heading feels too cramped, the Y in Courtney is getting clipped," that's a design observation. Figuring out the fix was padding-bottom: 0.75remon the gradient text span because background-clip: text clips descenders? That's engineering knowledge I didn't have. Having both in the same loop, in real time, was genuinely different from any handoff I've been part of.
69% of developers spent part of 2025 actively learning new coding techniques or a new language, according to the Stack Overflow Developer Survey. What's different about learning React as a designer, in 2025, with an AI pair-programming partner in your terminal: you skip the theory-first phase entirely.
I didn't do a course. I didn't read the docs front to back. I just started making things and asked questions when they broke.
After a few weeks on this site, I actually understand components now. Not because someone explained them abstractly, but because I kept hitting the same problem: I was copying the same Section component with the same scroll-fade logic across four case study pages. Extracting it into a shared FadeInSection.tsx made it click. I get why it matters now because I felt the cost of not doing it first.
State clicked for me when I was working on the typewriter effect in the hero. There are three things that have to stay in sync: which role is displayed, whether it's typing or deleting, and what characters are currently showing. Seeing that as three useState hooks, then watching what happened when one changed, made it tangible in a way no abstract explanation would have.
Making things break and then understanding why they broke turned out to be a faster learning path than reading about them first. I'm not sure that's universally true, but it was true for me.
Tailwind CSS now exceeds 75 million npm downloads per month, the most of any CSS framework, and 51% of developers use it daily according to the State of CSS 2025 survey. That dominance isn't an accident. From a designer's perspective, it makes complete sense.
If React was the foreign part, Tailwind was the part that clicked immediately. The utility-class model (describe exactly what you want, right in the element, no separate stylesheet) maps almost directly to how I think in design tools. In Figma I'm looking at a frame and setting properties on it. Tailwind feels like that.
Tailwind v4 has an @theme block where you define your design tokens (colors, spacing, fonts) and they become available as utility classes everywhere in the codebase. Setting up --color-purple: #8059C4 and then using text-purple, bg-purple, border-purpleanywhere felt like a design system that was actually enforced by the tooling. Not just documented in a Figma library that slowly drifts from what's in production.
Figma variables and Tailwind's @themetokens solve the same problem from opposite sides of the handoff. If you've used one, you already understand the other.
Teams using AI-assisted development report 51% faster task completion on average, according to Second Talent's 2026 vibe coding report. For me the speed gain wasn't about writing code quickly. It was about layout exploration: running five structural hypotheses in parallel without any of them touching the live site.
I kept a main branch for the live site and a layout-exploration branch for experiments. At one point I had five different homepage layouts as separate routes (/layout-1 through /layout-v2), each testing a different structural hypothesis. Two-column hero vs. bento grid. 2x2 card grid vs. featured-first layout.
“Having five layout variations living simultaneously in routes I could just navigate to felt closer to having an artboard-per-concept in Figma than anything else I'd tried in a browser.”
Holding multiple options open, navigating between them in a real browser, seeing how they felt at different viewport sizes: it changed how I think about layout exploration in code. It's slower to set up than Figma. The fidelity of what you're evaluating is so much higher though.
44% of non-developer vibe coding users are building UIs as their primary output, the largest single use case in the category (Second Talent, 2026). That tracks with my experience. Once you have actual control over the code, making the UI feel alive becomes a design problem you can finally solve end to end.
Animation was the part I was most intimidated by going in. It ended up being the most fun. Installing Framer Motion unlocked a level of expressiveness I hadn't been able to get anywhere close to before. Spring physics, stagger delays, viewport-triggered entrance animations. Stuff that takes careful choreography in After Effects or Principle. Suddenly achievable with a transition prop.
The SVG animation work was a whole separate rabbit hole. Morphing blobs, orbiting rings, radial stat arcs, spark bursts on the CTA hover. I built an entire examples page just to see what was possible before deciding what to actually use. That felt like a very natural design process: explore broadly, then select deliberately.
39% of designers name cross-discipline learning as the single most effective fix for designer-developer friction, according to the CollabSoft 2025 designer survey. I used to nod at that stat. I believe it differently now.
I expected to learn about code. The more interesting thing I learned was about design decisions I'd been making for years without fully understanding what they meant downstream.
When you're writing the component yourself, "make the cards responsive" stops being a note in a spec and becomes a concrete question you have to answer right now: at what breakpoint? What does the grid collapse to? What happens to the image ratio? Those decisions exist in design tools too, but they get deferred or left implicit in a way that code just doesn't allow.
I stopped writing specs that said "responsive" and started having much more specific opinions about exactly how things should behave at 375px. Code made me a more precise designer.
I also came out with a different kind of empathy for engineers. Not the generic "devs have it hard" take you hear in design communities. Something more specific. I now get why a spec comment like "subtle animation on hover" can turn into a 45-minute conversation. What I mean by subtle and what's actually achievable in a sprint are often two different things. Having to make those calls myself changed how I write specs for others.
The site is live and still evolving. This blog is new. I want to write about design process, strategy, and whatever I'm currently messing around with. There are three more case studies to write, animations I built examples for but haven't applied yet, and probably a refactor I haven't thought of yet that'll seem obvious in six months.
If you're a designer who's been curious about coding but keep putting it off: the curve is real, and it's worth it anyway. Not because every designer needs to code, but because building something yourself has a way of making you better at designing things for other people to build. That alone was worth the awkward early sessions where I had no idea what I was doing.
Yes. 63% of vibe coding tool users in 2026 are non-developers (Second Talent, 2026). Claude Code is particularly suited to this because it runs in your terminal and edits files directly. Less like a chatbot, more like pair programming with someone who can implement what you describe.
Basic HTML and CSS literacy helps (knowing what a div is, being comfortable in inspect element), but it's not a hard requirement. The bigger thing is having clear design intent. Claude Code handles implementation; you need to know what you're building and why.
For a designer comfortable in Figma and curious about code, Next.js with Tailwind CSS v4 is a solid starting point. Tailwind's utility-class model maps closely to how designers set properties in design tools, and it's now the world's most downloaded CSS framework at 75M+ npm downloads per month (State of CSS 2025). Next.js handles routing and deployment cleanly without needing to configure a build system from scratch.
The biggest shift is fidelity. Evaluating a layout in a real browser at actual viewport sizes is a fundamentally different experience from a Figma prototype. You catch things — text overflow, grid collapse behavior, touch target sizing — that prototype tools paper over. The cost is setup time; the gain is accuracy.
Writing precise specs for yourself. When you're both the designer and the implementer, 'make it feel right' isn't a spec. You learn quickly that every visual decision is a set of concrete choices about breakpoints, spacing values, and timing functions. That specificity turns out to make you a better designer for everyone else too.