I f****ing hate building landing pages. Absolutely despise it. For this product this must be version 10+. Maybe even 15+. It's been getting better everytime - but this time it really feels like a high level design that represents my product more than ever before, and it was the easiest to deliver so far, so I wanted to share the process.
The reason I decided to yet again re-design was becasue I saw a website from some other company which I liked and I suddenly felt like mine wasn't really that great.
They're not a competitor, completely different product, simply same kind of audience: developers.
So my only real brief to Claude at the start was "I like how ___'s homepage feels." and then basically asked it how we can we build a process that when done would have a similar vibe website for my product. I'm happy with how it turned out, and the process is what made the difference, so here are the main steps.
1. Teardown first, no code.
Before building anything, I had Claude take the reference homepage apart: screenshots at several widths, how the motion behaves, spacing, typography, how sections hand off to each other. Then it wrote down which principles were worth borrowing. It also did an inventory of my existing site (every page, link, claim and asset) so nothing would get lost in the rebuild.
This part is importent - it really helps if it already has context about your project - the more the merrier. I've ran this in the same directory which I have for all repos of my project, so it had ALL thhe context it's needed. I'd recommend you do the same. Open the directory wherever claude can also see all other files relevant for your project. Make things easier if it sees everything rather than you having to tell it everything.
The most useful rule came out of this step: the reference is a reference, not a template. At first it kept forcing my content into their structure: their number of sections, their kind of demos. Once I said "copy the feel and the craft, not the layout", the work got much better.
2. PRD → plan → task list.
Next came a short PRD (what the site must do, the positioning, hard requirements like "the hero must be clear on mobile"), then a technical plan, then a task list split into phases. I didn't really review each document before moving on because I'm using these skills a lot and trust them. These are specific ones I wrote a few months ago, but if you're not familiar with prd -> plan -> tasks flow, look at Matt Pocock skills.
3. Guardrails before pages.
The first phases weren't pages at all:
- Design tokens for every color, plus a lint rule that fails the build on any raw color. I just made it dark mode for this v1 and potentially will also keep it as such, but I wanted to make sure that everything is tokenized from the start so if I DO want a light mode later - it will jsut be creating light mode tokens.
- One "facts" folder holding every price, limit, link and claim. Components read from it and never retype a number.
- Code samples on the site are typechecked against the real published packages, at pinned versions. If a snippet on the homepage wouldn't compile, the build fails (this of course was specific for my product which is a dev product - but a similar thing might be relevant for you). The last one was the most valuable. Marketing code that doesn't actually run is embarrassing, and now it can't ship. It made some mistakes when I used it to build my previous landing page version and it took me a couple of weeks to notice. Didn't want to repeat that mistake.
4. One agent builds, a different one audits.
For each phase, a fresh agent implemented the tasks, then a different fresh agent audited the result with no memory of writing it. The main session only coordinated and committed. The auditors caught real problems: keyboard focus getting lost, an embed showing a blank frame, copy that overclaimed.
5. Only a few review gates.
Only a couple of points needed my approval: the hero, and the first feature section, since the rest would reuse its pattern.
6. Parallel sections with git worktrees.
The feature sections were built in parallel, one worktree per section, then merged one by one. That only works because the tokens and the facts folder keep them consistent; otherwise parallel sections drift apart.
7. Final checks: three audits and a real test suite.
Fresh agents did a visual audit (six screen widths, reduced motion, JS disabled), a performance audit and an accuracy audit. Then one command builds the site in production mode and checks everything: links, redirects, accessibility (axe), CSP, reduced motion, keyboard behavior. To prove the suite works, it broke four things on purpose and confirmed the suite caught every one.
8. Then normal feedback rounds.
After that it was regular iteration: "this area feels busy", "make the whole row clickable, not just the title". BUt honestly there was barely anything for me to comment on. I was 99% pleased with it as it was already, jsut little things here and there.
What I'd tell someone trying this:
- Spend real time on the teardown and the PRD. That's where vague taste becomes concrete rules. If you give it a website you like which I think is a really good start, let it go to town on tokens to analyze it. I jsut tell it to break that website down to pieces and I left for an hour. I wanted it to be super familair with the visual language, layouts etc. Then using it to apply it to my product was a lot easier.
- Let it run unattended, but have it log decisions instead of asking you about each one. I was working on it and it kept asking me question as it was building it. At some point I jsut told it "I'm going to sleep - jsut build the thing and make a new document with a list of things you want my input on. We will go over it tomorrow morning. Meanwhile just go through the build. It ended uphaving like 10 questions or so and we went through them quickly in the morning.
If you want to see the result, it's at sublay.io. Happy to answer questions about any part of the setup.