Mestizen Studio needed a website that actually reflected what the studio stood for — multicultural, opinionated, and polished. Not a template. Not a Webflow starter. Something that felt genuinely built, with real craft behind it.
The challenge: I had the design instincts and front-end fundamentals, but building a complete multi-page system from scratch — with animations, a bilingual architecture, and a full design system — at the speed I needed meant working differently. I used Claude as my coding partner throughout.
This is the story of how that process actually worked: where I set the creative direction and made every design decision, where I used AI to accelerate the build, and where I jumped back into the code myself to get things exactly right.
"Claude didn't design the site. I did. Claude helped me build it faster than I could alone — and I knew enough to fix it when it got things wrong."
— Carlos, Founder & Lead Designer, Mestizen StudioFour distinct phases — each with a clear human/AI split. The creative decisions were always mine. Claude handled the heavy lifting of code generation.
Set every creative decision first. Color palette, typography pairing, spacing system, animation philosophy, brand personality. This happened in Figma and in my head — not in Claude.
Built the homepage first as the design system in motion. Every token, animation pattern, and component pattern was established here before expanding to service and case study pages.
Claude would generate. I'd review in the browser, spot visual problems or structural issues, then either correct Claude's output with precise instructions — or fix it directly in the code myself.
Once the homepage was solid, expanded to service pages (Webflow, Shopify, UX/UI, Brand), case study pages per project, and a full Spanish translation under /es/.
Before writing a single line of code, every visual decision was locked down. The design system became the brief I gave Claude for every subsequent page.
All motion is purposeful and subtle. GSAP handles entrance animations and ScrollTrigger sequences. CSS handles loops and micro-interactions.
Key principle: The design system was documented as DESIGN_SYSTEM.md and tokens.css in the project repo. This became the single source of truth I fed into Claude as context for every page I built — keeping every file consistent without having to repeat myself on every prompt.
The landing page wasn't just the homepage — it was the proving ground for every token, every animation, every component pattern. If something worked here, it worked everywhere.
I specified the section order, content strategy, and visual hierarchy. Claude generated the structural HTML and CSS. I reviewed, iterated, and refined — section by section.
Dark bg · floating SVG leaves · blob canvas · GSAP entrance · cursor glow
CSS infinite scroll · mint background · service keywords
Cream bg · 2-col grid · about cards · animated entrance
Dark alt bg · 3-col card grid · hover shimmer · GSAP stagger
Dark bg · 2-col · numbered list · purple gradient visual card
12-col editorial layout · 4 gradient work cards · hover scale
Mint bg · staggered scroll reveal · Bricolage Grotesque large
Dark bg · radial glow pulse · Calendly integration
mestizen.com — final homepage
Every technology decision was intentional. I chose tools I understood well enough to direct and debug — not just use as black boxes.
GSAP was the clear choice for animation — battle-tested, performant, and expressive. I knew its API well enough to specify exactly what I wanted, so Claude could write the animation code precisely.
ScrollTrigger handled all scroll-based reveals. I used data-reveal attributes on elements as the trigger pattern, keeping the JS loop minimal and clean.
I used Claude as my coding partner — not my designer. I'd brief it with the design system context, the section I was building, and specific visual requirements. It would generate the HTML/CSS structure.
The feedback loop was the most important part: I'd load the output in the browser, identify issues (layout breaks, wrong spacing, SVG not rendering), then either correct Claude with precise instructions or fix it in the code directly. My HTML/CSS knowledge meant I could always tell why something was wrong.
No React, no bundler, no dependencies beyond GSAP. Deliberately. A vanilla codebase stays transparent — I can open any file and understand it completely. It deploys instantly to GitHub with zero config.
CSS custom properties carried the design system. Every spacing value, color, radius, and transition lived in :root from day one. When I needed to tweak the dark background color across 12 files, I changed one token.
Cursor as the IDE kept DESIGN_SYSTEM.md always in context when writing code — an AI-assisted editor that knew the project's rules without me having to re-explain them every session.
GitHub gave instant deploys from Git with zero infrastructure overhead. The multi-language architecture (EN at /, ES at /es/) was handled purely through folder structure — no server-side routing required.
The real skill wasn't prompting Claude — it was knowing how to review the output and close the gap between what was generated and what I actually wanted.
Section ID, component names from the design system, exact CSS classes to use, what not to touch. The more specific, the less cleanup.
Copy the output into the file and open it with VS Code Live Server. Look at it — don't just read the code.
Spacing off? SVG misaligned? Animation fires at the wrong point? I could diagnose this because I understand CSS layout and GSAP.
Small issues: fix directly in the code. Structural problems: tell Claude exactly what's wrong and how to fix it. Never just "this is wrong."
When a section looks and behaves exactly as designed, commit to Git. The next section gets the same treatment from a clean base.
The final site deployed to GitHub — multi-page, bilingual, fully animated, zero frameworks.
Not about replacing skill. About multiplying it.
The moments Claude produced the most useful output were when I'd already made every design decision before prompting. Tokens, layout intent, component names, animation behavior — the more decided I was, the better the generation.
AI code rarely looks broken — it looks reasonable. Catching the subtle difference between "works in the browser" and "looks exactly as designed" required real CSS and layout knowledge. This skill gap is what separates good AI-assisted work from mediocre output.
Feeding DESIGN_SYSTEM.md as context to every conversation meant Claude always knew the color tokens, the type scale, the spacing system. I never had to re-explain the palette. The document became the brief.
The most reliable pattern: ask Claude to change only one thing at a time. The more open-ended the task, the more likely something else breaks. "Only modify the hero section. Do not touch any CSS outside it." Every time.
Translating 8+ pages to Spanish while updating all asset paths from absolute to relative (../assets/) was tedious work that Claude handled efficiently once I understood the path convention. I reviewed every output, but the heavy lifting was automated.
Every file was mine. I understood what every class did, every GSAP call, every CSS variable. That meant I could debug confidently, add features cleanly, and never feel blocked waiting for AI to fix something I could handle myself.
If you're a studio, agency, or creative building their web presence — I can help you build it right. Same approach, applied to your brand.