How I Fully Redesigned and Built Monofactor with Claude
I have a tendency to neglect my portfolio for years. And so was it again, left untouched for 5 years.
My portfolio, Monofactor is actually online since 2004 and this is the 9th version of it. Before I replaced it with this, it was a WordPress website which I also hand-built from scratch.
This time, I wanted to go modern tech. And Also...
No Figma. Seriously.
I know how that sounds. I'm a designer. Figma is home. But for this project, I wanted to test something: can we skip the design-to-dev handoff entirely and go straight from idea to live site?
Yes. With a big caveat: You still need to think like a designer.
Claude or any other AI tool don't replace taste or creative direction. What it replaces is the mechanical translation layer. Instead of designing screens, exporting specs, and then watching someone re-interpret your intent in code, I went straight from "I want it to feel like this" to a working thing in the browser. Every decision was still mine. The execution was the conversation.
The stack is NextJs, Tailwind, Threejs for the shader, and Anime for the animations(mind you, not motion like everyone or every AI else). Every component was prompted, reviewed in the browser, and iterated through Claude Code.
Starting with the Layout
First pass was the bones: The grid, the typography system, the color tokens, dark mode. I described the structure I wanted, Claude built it, I looked at it in the browser, prompted changes. No mockups. No redlines. Just back and forth.
One early win: I asked for a dark mode toggle that doesn't flash white on load (you know the flicker, every dark mode site has it unless you handle it). Claude set up a system where the theme is applied before the page even renders. Tiny detail, but the kind of thing that takes an hour to research and implement manually, and about 30 seconds to prompt.
The whole layout came together this way. Describe, review, adjust. The browser is the canvas.
The Hero Shader: A ShaderToy Effect, Rebuilt for the Real World
I found a shader on ShaderToy — this moody, atmospheric cloud effect that had the exact energy I wanted for the hero.
But I couldn't just copy-paste it in. ShaderToy is a playground and shaders there are built to run fullscreen as tech demos, not as background elements on a real website. This one was brutally GPU-heavy. It would drain batteries, freeze laptops and turn phones into hand warmers.
More than performance, though, the creative direction was different. I didn't want a screensaver. I wanted a subtle atmospheric texture that supports the content, something you feel more than stare at.
So I prompted Claude for a complete rebuild. Not a port but a full rethink. I needed it to:
Run efficiently enough for a scrollable page (not a dedicated fullscreen demo) and run at 60fps for almost all devices.
Respond to mouse movement so it feels alive.
Pull its colors from my design system so when you toggle dark mode, the shader shifts with everything else
What Claude built was clever. The shader renders at half resolution and upscales smoothly, cutting the GPU work dramatically. When you scroll past it, it pauses entirely. There's a toggle between high-fidelity mode (every frame) and a lighter mode that only renders every third frame — which actually creates a nice natural motion blur as a side effect.
The color system is the part I love most. The shader's warm and cool tones aren't hardcoded hex values and they're wired directly to my Tailwind design tokens. Change --color-zinc-600 in the CSS and the GPU follows. Dark mode toggle? The shader shifts with it. The design system reaches all the way into the graphics pipeline. That felt like a breakthrough.
Mouse interactivity adds the final layer: Move your cursor and the clouds shift with you. Closer elements react more than distant ones, so it has depth. It feels physical without being distracting.
The Bottom Nav: It Reads the Page Behind It
This was the wildest component to prompt. I wanted a bottom nav where each section gets a thin vertical line, and as you scroll, the line for the active section grows taller while the others shrink: A smooth wave that follows your position on the page.
But the real trick is the color. The nav sits at the bottom of the screen, and as you scroll, whatever's behind it changes: Light backgrounds, dark sections, images, the shader. I wanted each nav item to independently detect what's behind it and flip between light and dark styling accordingly.
Think about that for a second. One nav item might be sitting over a white section while its neighbor is over a dark image. They each need to be readable against their own background, independently, in real time, as you scroll.
Claude built a system that literally samples the page at each nav item's position, figures out the luminance of whatever's behind it (while ignoring the nav's own frosted glass blur otherwise it'd just read itself), and switches each item's color independently. Sections can also override this with a simple attribute if the automatic detection doesn't get it right. That’s basically Apple’s most hated glass nav luminance being fixed.
On mobile, the nav becomes horizontally draggable with spring physics — flick it and it bounces back naturally, or it auto-centers on the active section as you scroll.
The whole thing has a progressive frosted glass blur behind it — not a single blur layer (which always looks harsh at the edges) but ten stacked layers with graduated masks. It fades in smoothly.
Blink Text: An Animation I Prototyped, Claude Productionized
I had been playing with a text reveal animation using Anime.js: Words appearing with a quick double-blink before settling. That rapid flicker that feels like something powering on. I'd gotten the timing right in a rough prototype and knew the feel I wanted.
I described the concept and timing to Claude. It built a production component that splits text into individual words (or characters), then runs each one through a staggered sequence: fade in, hold, blink down, blink up, blink down again, settle. Each element gets slightly randomized timing so it feels organic rather than mechanical. The animation triggers once when the element scrolls into view.
The key insight here is that I didn't need to explain how to build it: I explained what it should feel like. "Like old monitors warming up." "Each word should feel like it's locking into place." That's designer-to-AI communication, and it works surprisingly well.
Thinking Text: The Little Detail That Sells It
The hero has a small looping animation: A spinning asterisk, a blinking cursor, and text that cycles through words like "Analyzing", "Pixelating", "Figging", "Making Logo Bigger", "Clauding", "Stakeholding”. Each word revealing through a scramble effect. Characters lock in left to right while the leading edge randomizes. Just like how Claude thinks.
It's a small touch, but it sets the tone for the whole site. The humor in the word choices, the pace of the reveal, the way the cursor blinks in that mechanical binary way: It all says "AI-native" without being heavy-handed about it.
Three animations run simultaneously and independently: the spin, the blink, and the scramble. Claude handled the orchestration. I handled the word list.
What I Actually Learned
The biggest takeaway isn't about any single component. It's about the holistic workflow.
The gap between intention and implementation effectively disappeared. Normally there's this lossy compression step where a design gets translated into code and things drift.
Spacing gets approximated. Animations get simplified. Edge cases get skipped. When you're prompting an AI that writes the actual production code, that gap closes.
What you describe is what gets built. If it's wrong, you describe the fix and it's immediate.
However, you still need to be a designer. Claude didn't make creative decisions for me. It didn't pick the shader, choose the animation timing, decide the nav should be luminance-aware, or write the funky word list. Those are all taste calls. What it did was make the cost of trying ideas near zero. "What if the nav detected the background color?" is a question that normally means a day of R&D. Here it meant a prompt and ten minutes of iteration.
The browser is the design tool. I was reviewing real layouts with real interactions on real devices at every step. Not static mockups that approximate the final thing — the actual final thing, updating in real time. That changes how you design. You catch issues earlier. You discover happy accidents. You iterate on feel, not just appearance.
I'm not saying this replaces Figma for every project. Not at all. If you're designing a complex product with a team of five, you need shared visual artifacts and collaborative tools. But for a solo project where you have the vision in your head? Going from brain to terminal to browser is a different kind of fast. And it's only getting faster.
The site is live. Every atmospheric cloud shift, every luminance-sampled nav flip, every scrambled character — all prompted, iterated, and shipped through Claude Code.