How We Designed Our Whole Site
Without Figma

Introduction

This is How We Grow, our weekly log of what we're doing to grow Kai. Last week we covered the branding system Dave built for us, the green mascot, the colors, the tone (see #004: How We Built a Brand AI Can Run). This week we started putting it to work.

Lambert did most of the heavy lifting, and I helped steer the project in the right direction. By the time you read this, his work is live on the site. This week I sat down with him to look back on how we handled it and what we learned along the way. Here's what we're covering:

• Why we made the call to rebuild
• Why it took 10 days, more than twice what we'd planned
• What it finally looks like
• What we'd recommend if you take on a similar project

Prefer to watch or listen? Here's the full episode

Why we rebuilt the site right before launch

Tearing down your site weeks before a public launch sounds reckless. We did it because leaving it up was the bigger risk, and two things were broken at once.

The messaging was outdated. Our feature pages were built during a hackathon, off an early knowledge base that was really a guess at the final product. Three months later, the product had changed a lot. New integrations. Kai handled meetings and emails differently. We built a new Kai MCP, a new Slack bot, and the whole strategy around it shifted. The pages weren't telling the full story anymore, and they no longer matched what the app actually does.

The hidden cost: LLMs are already scraping our pages to learn what Kai is. Feed them outdated copy and they tell the wrong story, which is slow and expensive to correct later. We keep what's written about us current so they get it right from the start.

The design no longer matched the brand. Last week's work gave us a new brand, and we'd put real time into leveling up the quality of our designs. Every page we hadn't touched since looked outbranded next to the new homepage. A visitor should feel like they're on one website whether they land on the homepage, a feature subpage, or the product itself, and we didn't have that.

So we made the call: rebuild the feature pages and subpages to match the messaging of the actual app and to do justice to the new brand, with a design experience that stays consistent across every surface, from the homepage to the subpages to the product.

The old daily-planner page. Stale value proposition, off-brand design, both at once.

We designed the whole thing in code, and never opened Figma

Here's Lambert's setup:

• Cursor as the IDE.
• A knowledge base of our value-proposition pages, written as Markdown files.
• The site codebase alongside it, hosted on Vercel.
• Claude Code runs the whole thing. No CMS, no Webflow, no design handoff.

It all happens in the IDE. That's where we build, and that's where we ship.

For this project, Lambert tried a few design tools first. He started with Figma and quickly found that even for branding this design-heavy, a code editor iterates faster. Then he tried designing with Claude directly, which felt thin next to what we already had: the depth of our codebase and the branding documents living in our GitHub repo. The only real option left was to build directly in Claude Code, in the repo, where all that context already lives.

Our first instinct was a design system. We killed it.

We'd done this before. For the brand, we built the whole system first, then made every asset downstream from it, and it worked. Doing the same here felt right: design a system first, then build the pages on top.

A design system makes every page look the same

The foundations were never the problem. The color palette, the buttons, the corner radii, the spacing: locking those down is useful, and we did. The trouble was the layer above. A design system also hands you fully designed blocks, a hero, an FAQ, a feature row, that you reuse across pages, and that reuse is the whole point: every page built from the same blocks looks consistent. But we didn't want consistent feature pages. We wanted unique ones, landing pages immersive enough that you can feel the effort that went into each.

That's the wall Lambert kept hitting. He wanted every block to feel hand-made, and a shared block can't. He'd come back to the system, try to assemble each page from the same sections, and watch the pages flatten into sameness. After enough rounds of that, he kept the foundations and set the blocks aside, for now. A system like that is great once you know exactly what you want, but when every page needs its own custom design, the blocks have to come after the designs, not before.

The design system Lambert built. Every token, color, shadow, and component in one place. The foundations stuck. The prebuilt blocks didn't.

So every block is bespoke, and the system comes last

With the system parked, Lambert built each page from scratch. He iterated by working in parallel: he'd spin off several git worktrees, each holding a different version of the same landing page, each taking a very different angle, then compare them, pull the best idea from one worktree into another, and merge. Multiple prototypes of the same page, all spun up in plain English.

How one page gets made. Several worktrees run in parallel, most get dropped, and the best ideas merge into what ships.

Right now every block on the site is one-off. We're not pulling from shared components, and for pages meant to feel unique, that's the point. The cost is that nothing has a single source of truth. When the same block appears on several pages, each page carries its own copy in the code, so updating how it looks or behaves means editing every copy by hand.

We already know how that cuts the wrong way, because the first version of the site was built with no rules at all. The same FAQ might live as three different blocks in the code, one on the homepage, one on a feature page, one on a free tool. Nothing looks off on screen. Then you ask Claude to optimize "the FAQ," it fixes one of them, and you're left staring at the other two wondering why your change didn't take.

We're taking that cost on purpose for now, because unique pages are worth it. But the duplication is the next thing we'll fix. The system comes last, not never: once the designs are locked, we build it on top and reconnect every block, so the parts that should stay consistent get a single source of truth. Then changing a CTA or the texture of a block is one edit, and every page picks it up.

What "good" looks like, and the versions you will never see

Lambert's bar for a block is a "wow" at every scroll. If a section doesn't land, he iterates, and he'll spend 2 or 3 hours on a single block to get there. Most of that work, nobody ever sees.

A couple of whole directions didn't survive. There was a dark mode that looked good but needed more thought before it could go site-wide, so we parked it. There was also a much louder, fully colorful version that pulled in every color from the brand system: pink in the background, blue, green, and yellow in the blocks. We decided it was too much and pulled back.

Dark mode, which we dismissed.

What it finally looks like

That's what we cut. Here's what we kept. Every feature page got rebuilt in code on the new brand, the version that won out of all those parallel worktrees.

The same daily-planner page, rebuilt in code on the new brand.

Walk through the rebuilt pages yourself: Ask Kai, Meetings, Email, and Daily planning. We're rolling the redesign out gradually, so depending on when you read this, some or all of the site may already be on the new design.

Before we ship, it has to pass

We decided to ship each page complete, never half-built. But before any of it goes live, it has to clear a set of checks:

• Mobile UX. It has to feel right on a phone, not just on a wide desktop screen.
• SEO. Titles, metadata, and headings carry over so the rebuild doesn't cost us rankings.
• Internal linking and technical SEO. The links between pages and the technical plumbing still hold.
• Performance. A Lighthouse gate, because the redesign leans on a lot of animation, a new color palette, and images that all need optimizing. We built this gate after an early performance miss, back in HWG #001, so every deploy runs it now.

Once everything passes, we ship.

What I'd do differently

Three things, if we ran it again.

Do the navigation and messaging research first, before any design. We ran them in parallel. I was laying down the site navigation and writing crystal-clear docs on our features and value proposition, while Lambert had already started designing. He didn't have clarity on the end goal or on what the navigation should feel like, so he was designing without a compass. We lost a couple of days there. What fixed it was nailing two things per page: the navigation of that page, and exactly what we wanted that page to say. Once that was clear, Lambert's design work sped up noticeably.

Don't force a design system onto something meant to be new. A design system is the right call almost every time. It's the wrong call when the whole point is new blocks and a new identity. There are really two layers to it. The atomic elements, the buttons and corner radii and base tokens, should be set early and never move. The blocks, components and sections built on top should be designed one by one first, then pulled into a system, then migrated back to it as shared code. We did it backwards, building the system first and trying to apply it to the pages, and lost a few days to that.

Tighten the feedback loop. Lambert was sharing work every two or three days. On a project this visual, that's too slow. The fix is a Slack automation: every day at 5pm the latest preview gets posted to the team, everyone clicks, everyone reacts. The more feedback you get, the faster you iterate. Iterating alone for days is a failure mode, and perfectionism without anyone else's eyes isn't the flex it feels like in the moment.

The whole thing took about 10 days. If we did it again with those three fixed, it'd be more like four or five. The one thing we got right from the start: this was Lambert's only job for the stretch. For a project like this, one person fully dedicated with no context-switching matters more than almost anything else.

What's next

We've started rolling the new design out across our four key feature pages and the integrations pages. Next is to apply it everywhere else: the blog, the comparison pages, and everything around them.

As for me, I've been spending more time on everything pricing and analytics. I've started building the architecture for how we, as a growth team, can work with our own data: using AI to answer analytics questions, spin up dashboards, and pull what we need on the fly. I've also started preparing our big launch on September 1st, so stay tuned, there's a lot more coming on that.

We're still in open beta, onboarding around 20 users a day. There are 1.2K people on the waitlist right now. If you want to give Kai a go, you can sign up here and you'll get access to the open beta. Thanks for following along.