Version 1: The Template Clone
I needed a personal site. I'd been putting it off for years — you know how it goes. So I grabbed a Next.js starter template, changed the colors, swapped my name into the hero text, and called it a day.
It looked fine. It also looked like every other Next.js starter site on the internet. The README still referenced a dashboard and login page that didn't exist. The middleware was named proxy.ts because I couldn't commit to calling it middleware. The tagline was "Marketing Strategist by Day, AI Enthusiast by Night" — which is what you write when you can't decide what you actually are, so you claim both and own neither.
I published it anyway.
Version 2: The Parallel Redesign
A few weeks later, the design started bothering me. The auroras felt overwrought. The bento grids looked like every AI startup landing page. So I did what any reasonable builder would do: I created a /v2 route.
Same codebase. Same architecture. Same component library — just new homepage components. HeroV2, BentoGridV2, BuildsAndSystemsV2. I'd iterate on the /v2 page at night, compare it against the live version, tweak spacing and type scale. I told myself I was redesigning.
I was restyling a site whose positioning I'd already outgrown. The /v2 page had the same tagline, the same two-worlds framing, the same template-era architecture underneath. It was a design sandbox with a URL — a new paint job on a house I didn't want to live in anymore.
The Breaking Point
Here's the thing I kept avoiding: between v1 and v2, my actual work had changed. I wasn't splitting time between "marketing strategy" and "AI enthusiasm" anymore. I was building AI-native GTM systems. Running Claude Code sessions 4-10 times a day. Teaching a course called GTM Engineering. Operating a second brain that an AI agent maintained.
The positioning was wrong. And you can't restyle your way to a new positioning.
So I did the thing you're not supposed to do: I burned it down.
The Rebuild
New repo. New positioning: "I build AI-native GTM systems." Not "I do marketing and also like AI." One identity, not two worlds colliding in a portfolio site.
New design language: controlled neo-brutalism instead of animated auroras. Hard corners. Structural lines instead of shadows. One accent color — Signal Lime — used so sparingly it's a surprise when you see it. Three fonts with actual rules: Syne for display only, IBM Plex Sans for everything else, IBM Plex Mono for metadata. The rule is Syne stays under 20-25% of page type.
The design system lives in a file called DESIGN.md — 132 lines. It has a section called "Confirmed Rejections." Here's what's banned:
- No gradients. None. Not a hint.
- No glassmorphism. Leave the frosted glass to the fintech landing pages.
- No floating blobs. They follow your cursor and add nothing.
- No constant animation. Motion must have a purpose or it doesn't happen.
- No cyberpunk or crypto aesthetics. I'm not building the future. I'm building systems.
- No excessive cards. Cards are for e-commerce, not for people.
The rejection list is as important as the directive list. Every designer has a palette. Few have a list of things they explicitly refuse to do.
There are other rules. "The One Signal Rule": if more than one region of a viewport is lime, the accent has stopped signaling. "The No-Shadow Rule": a box-shadow anywhere on this site is a defect, not a stylistic choice. These aren't preferences. They're laws.
The tech stack was simplified, not expanded. I removed Velite, Prisma, Supabase, and TanStack Query — not because they're bad tools, but because they didn't serve the new purpose. The old site needed a blog pipeline and a contact form database. The new site is a case study showcase with a Resend-powered contact form. Different job, different tools.
The content model changed completely. The old site had three generic starter blog posts about Next.js 16 and React 19 — the kind of content a template ships. The new site has three flagship case studies and three foundational essays. Real work. Real writing. Real positioning.
What I Learned
There's a difference between a redesign and a rebuild, and mistaking one for the other is how you waste months on a /v2 route.
A redesign says "I look different." A rebuild says "I am different."
If your positioning, architecture, or content model needs to change, you're not redesigning. You're lying to yourself with a new paint job. The /v2 route was comfortable because it didn't require me to admit that the old positioning was wrong. I could iterate on components without confronting the identity question underneath.
The rebuild forced me to write docs/plan.md before a single component was coded. It forced me to define what I refuse before I defined what I build. It forced me to ask: what am I actually selling here? Not "what looks good." What's the claim?
For the record: the rebuild was faster than the two redesigns combined. When you know what you're saying no to, the yes decisions happen fast.
So Here's My Question
What's the last thing you redesigned that you should have rebuilt?
The corporate rebrand that kept the same value proposition. The product refresh that didn't touch the architecture. The resume update that rearranged bullet points instead of rewriting the story.
That thing you've been iterating on for months? The one where you keep tweaking components but avoiding the hard question underneath?
Burn it down. The rebuild is faster than you think. And the /v2 route isn't fooling anyone.