Module 4, Lesson 1: Design the Landing Page

In this lesson, we’re picking up everything we’ve built across Modules 2 and 3 — all that research, documentation, and planning — and using it to ship our first real thing: a landing page.

Before We Start

Here’s what I’d expect you to have under your belt before this lesson:

From previous lessons:

• You should have your GTM, Market Research, Summary, and UX/UI documents already generated from Module 2
• WebStorm should be installed and working — we set that up in Module 3, Lesson 1
• Claude Code should be installed and you should be comfortable running it inside the WebStorm terminal — Module 3, Lesson 3

Tools / setup you’ll need:

• WebStorm (or VS Code as an alternative)
• Claude Code — running in the terminal
• Your documents from Module 2: GTM, Market Research, Summary, UX/UI doc
• GitHub account and git configured locally
• CleanShot (Mac) or ShareX (Windows) — useful for taking annotated screenshots to send to Claude

By the end of this lesson, you’ll:

• Have a starter repo cloned and set up locally in WebStorm
• Understand how to use the frontend-design skill with Claude Code to generate a professional landing page
• Know how to iterate on Claude’s output using screenshots and follow-up prompts
• Have a working landing page that you can preview in the browser — ready to go live

About This Lesson

Duration: ~27 minutes video + ~30 minutes practice
Skill Level: Intermediate
What You’ll Build: A working, styled landing page for your product — including a waitlist CTA, pricing table, and competitor-informed messaging

This is the lesson where everything we’ve been building toward starts to feel real. We’ve done the research, written the docs, planned the sprints — now we’re putting something live on the internet. I’ll show you how I use Claude Code with the frontend-design skill to go from zero to a polished landing page, and how to iterate on it using screenshots when the output needs tweaking.

Watch the Lesson

What We’re Covering

Here’s what I’m walking you through in this lesson:

• Cloning the starter repo — getting the boilerplate set up in WebStorm so you have a structured starting point
• Populating the .sales folder — copying your Module 2 documents into the project so Claude has the right context
• Running the first prompt — using the frontend-design skill to have Claude research your competitors and design the page
• Answering Claude’s clarifying questions — how to give Claude the answers it needs to make the right design decisions
• Iterating with screenshots — a practical workflow for refining the output when something doesn’t look right
• The waitlist framing trick — why I never make a waitlist look like a waitlist

1. Let’s Set the Scene (~0:00)

This is the module I’ve been looking forward to since we started. We’ve done a lot of upfront work — research, documentation, specs, planning — and now we’re going to actually build something you can show people.

The first thing we’re building is the landing page. Not the full app — just the page people land on to learn about your product and sign up. And the reason we start here is straightforward: I want you to be able to start driving traffic and collecting interest before the product is finished. That’s how you validate demand. That’s how you build a list of real people who care.

The goal of this page is to get people onto a waitlist. But here’s the thing — I don’t want it to feel like a waitlist. Nobody wants to wait. So we’re going to frame it as early access, as something premium and exclusive. The mechanics are the same; the positioning is everything.

2. The Core Ideas

2.1 Why We Start with a Landing Page

We’re not building the full app first. We’re building the page that proves people want it.

The reason for this order is simple: if nobody shows up to the landing page, or nobody signs up, that’s useful data. It means something about your positioning, your market, or your timing needs to change — and you’ve learned that before sinking months into an app. If people do sign up, you’ve got a list of real interested users to talk to while you build.

This is a bias toward shipping small things early and learning from them.

2.2 The Frontend-Design Skill

Claude Code supports what I call skills — essentially specialized instructions that give Claude a particular area of expertise. For this lesson, the starter repo includes a frontend-design skill that I’ve written specifically for this course. When Claude reads it, it knows how to approach landing page design the way a senior front-end designer would: distinctive typography, intentional layout, conversion-focused copy, and the kind of micro-interactions that make a page feel premium rather than generic.

You don’t need to understand everything in that skill file. What matters is that when you reference it in your prompt, Claude brings a much higher level of design thinking than it would otherwise.

2.3 Why the .sales Folder Matters

All the documents we generated in Module 2 — the GTM, the market research, the UX/UI doc, the summary — those aren’t just filing exercises. They’re the context Claude needs to design a page that’s actually tailored to your product and your market.

By putting those documents in the .sales folder and pointing Claude to them, you’re not asking it to guess who your users are or what your competitors look like. It reads your actual research and designs from that foundation. That’s why the output is grounded in real data, not AI guesswork.

3. Let Me Show You How It Works

3.1 Step 1: Clone the Starter Repo

The starter repo gives you a structured project with the right folder layout, MCP configuration, and the frontend-design skill already in place. You don’t have to set any of that up from scratch.

Go to:

https://github.com/deletosh/tpp-landing-page-starter

In WebStorm, go to File → New → Project from Version Control (or look for “Clone Repository” on the welcome screen). Paste the repo URL, then change the destination folder name to match your product — I named mine nurturo-landing-page.

3.2 Step 2: Populate the .sales Folder

Once the project is open in WebStorm, you’ll see a .sales folder in the left panel. This is where you put your documents from Module 2.

Here’s how to do it:

1. Open Obsidian (or wherever you saved your documents)
2. Right-click your vault folder and choose Reveal in Finder (Mac) or Show in Explorer (Windows)
3. Select your GTM, Market Research, Summary, and UX/UI documents
4. Copy them
5. In WebStorm, right-click the .sales folder and paste

When it asks about adding files to git — say yes. Don’t worry about what that means right now; we’ll get to git tracking shortly.

3.3 Step 3: Launch Claude Code

Open the terminal in WebStorm. I use Command + E and then type “terminal” — yours might open at the bottom of the screen by default. Position it however works for you; I like mine on the right side so I can see the project files on the left.

Now type:

claude --model claude-opus-4-6 --mcp-config .mcp.json

The --model flag lets me specify which Claude model to use. As of when I recorded this, Opus 4.6 is the latest. The --mcp-config flag points Claude to the MCP configuration file in the project root — that’s what gives it access to the tools we’ve set up (like Vercel, which we’ll use in a later lesson).

When it asks if you trust this folder, say yes.

3.4 Step 4: Run the First Prompt

Once Claude Code is running, paste in this prompt:

Review my app info in the .sales directory. Based on this, use the frontend-design skill to research my competition and design a standout landing page.

Before you design, ask me all the clarifying questions you need.

This is intentionally a two-stage prompt. I’m not asking Claude to just go and build something. I’m asking it to read my research first, then come back with questions before it touches any code. That step matters — the questions it asks will shape the design.

4. Answering Claude’s Questions

4.1 What to Expect

After Claude reads your .sales documents, it’ll come back with a list of clarifying questions. These aren’t bureaucratic — they’re genuinely shaping decisions about layout, messaging, and visual direction. Take a few minutes and answer them properly.

Here’s roughly what it asked me, and how I answered:

Do you have a logo? I said: just use a wordmark. No icon. Keep it simple.

Should I follow the colour palette from the UX/UI document? Yes — follow it exactly. That’s why we planned it.

Is this a pre-launch page? Yes.

Who is the primary visitor — the user or a related persona? In my case, the separated parent. The app has two user types, but the landing page is aimed at one of them specifically.

Do you have real testimonials? No. I told Claude to research real frustrations from public forums (Reddit, app reviews) and use those as social proof — framed honestly as documented community frustrations, not fake reviews.

Do you have app screenshots? No. The app isn’t built yet. I told it to use descriptive illustrations and icons instead.

Do you want a full pricing table? Yes — include it.

What should the primary CTA be? Waitlist — but don’t make it look like one. Frame it as early access. I was pretty direct: it’s a waitlist, but don’t make it look like one.

How aggressively do you want to reference competitors? Imply it, don’t name them. I don’t want to do free marketing for competitors, and I don’t want to create any legal exposure.

Just the main landing page? Yes. One page.

5. Iterating on the Output

5.1 First Pass

After you answer the questions, Claude will go research your competitors’ pages — actually visiting their sites and pulling real data — then build your landing page as index.html. Once it’s done, open the file in WebStorm and click the little browser icon (the WS icon) in the top right of the file editor. This previews the page locally in your browser.

Take a scroll through. Look at it on both desktop and mobile — mobile matters more for most products.

The first pass might be functional but a little generic-looking. That’s expected. What I got looked decent, but the font was common and the design felt a bit bland. So I ran a follow-up:

Update the design to make the page pop a bit more and not look generic. Use non-common font pairings and introduce elements that will be relevant to our prospects.

The second pass was noticeably better — distinct typography (DM Serif Display, if you’re curious), micro-interactions on hover, a sticky CTA that follows you as you scroll, and a visual language that felt more premium.

5.2 Fixing Specific Issues with Screenshots

Here’s a trick I use constantly: if something looks off visually, I take a screenshot of that specific area, paste it directly into Claude Code, and tell it what’s wrong.

On Mac, I use CleanShot. On Windows, ShareX. Take the screenshot, copy it, then in the Claude Code terminal do Ctrl+V (not Command+V on Mac — it’s Ctrl) to paste the image directly into the prompt.

Then just say what’s wrong:

[paste screenshot] This is not aligned. Please fix.

Or:

[paste screenshot] This logo looks tacky. Make it more premium — wordmark only, no icon.

Claude can’t actually see your browser, so it’s reading the code and making educated guesses. The screenshot closes that gap. If it doesn’t get it right on the first try, paste another screenshot and say: you can do better.

5.3 Checking Your Page

Before you move on, do a quick review:

• Scroll through on mobile — does everything look right?
• Click the CTA button — does it scroll or link correctly?
• Check the pricing toggle (annual/monthly) — does it switch?
• Any navigation links — do they go somewhere sensible?

The email input won’t actually do anything yet. We’ll wire that up in the next lesson when we connect to ConvertKit.

6. The Waitlist Framing Trick

I mentioned this briefly in the video, so I want to be explicit about it here.

Nobody wants to be on a waitlist. It signals “this isn’t ready” and “you’ll be waiting a while.” But early access? That signals exclusivity, priority, and that you’re getting something before everyone else.

The mechanics are identical. The experience is different. When you’re answering Claude’s questions about the CTA, push it toward framing like:

• “Get early access”
• “Join the founding members”
• “Be first in line”

Avoid: “Join the waitlist,” “sign up to wait,” “we’ll let you know when it’s ready.”

This is one of those things that sounds minor but has a real impact on how people feel about clicking that button.

7. Try It Yourself

Exercise 1: Get the Page Built

What to do: Clone the starter repo, drop your Module 2 documents into .sales, run the prompt, answer the questions, and get your first version of the landing page generated.

A nudge if you’re stuck: If Claude’s output looks too generic after the first pass, run the follow-up prompt about non-common fonts and making the page pop. That alone usually makes a significant difference.

How you’ll know it’s working: You can open index.html in WebStorm and see a complete, styled landing page in the browser preview.

Exercise 2: Iterate with Screenshots

What to do: Find something in your page that doesn’t look quite right — an alignment issue, a section that feels off, a logo or heading you don’t love. Take a screenshot of it, paste it into Claude Code, and tell Claude what you want changed.

What this is practising: The feedback loop that you’ll use constantly throughout the Build module. Getting comfortable with screenshot-driven iteration will save you hours.

8. You Should Be Able to Build This Now

Here’s what you can put together with what we just covered:

• A fully styled landing page for any product — pre-launch or live
• A waitlist page with pricing, social proof, and a competitor-informed value proposition

Check Yourself

• I’ve cloned the starter repo and have it open in WebStorm
• My Module 2 documents are in the .sales folder
• I’ve run Claude Code with the correct model and MCP config flags
• I’ve answered Claude’s clarifying questions and have a first version of the page
• I’ve previewed the page in the browser — desktop and mobile
• I’ve done at least one round of screenshot-based iteration

If Something’s Not Working

The Short Version

Here’s what I want you to walk away with:

• The landing page comes first: Get something online before the app is done. Validate demand, collect signups, talk to early users while you build.
• Your documents are your context: The research and planning from Module 2 isn’t just busywork — it’s the input that makes Claude’s output actually relevant to your product.
• Iterate with screenshots: Claude can’t see your browser. Screenshots close the gap. Take one, paste it, say what’s wrong. Repeat until it’s right.
• Never call it a waitlist: Frame it as early access. Same thing, completely different experience.

Quick Reference

Claude Code Command

claude --model claude-opus-4-6 --mcp-config .mcp.json

First Prompt

Review my app info in the .sales directory. Based on this, use the frontend-design skill to research my competition and design a standout landing page.

Before you design, ask me all the clarifying questions you need.

Design Follow-up Prompt

Update the design to make the page pop a bit more and not look generic. Use non-common font pairings and introduce elements that will be relevant to our prospects.

Screenshot Paste Shortcut (Claude Code terminal)

Ctrl+V   ← paste image into Claude Code prompt (use Ctrl, not Command, even on Mac)

Resources

Links & Docs

• Starter Repo — clone this to get started (referenced in Module 4, Lesson 1)
• Git Download — if git isn’t installed on your machine
• CleanShot (Mac) — screenshot tool used in the video
• ShareX (Windows) — screenshot tool alternative for Windows 
• WebStorm — IDE used throughout the course

Tools Used

• Claude Code
• WebStorm

Questions I Get Asked

Q: Do I really need all four documents in the .sales folder?

At a minimum, I’d say yes to all four: GTM, Market Research, Summary, UX/UI. Each one gives Claude a different dimension of context. Without the UX/UI doc, it won’t know your colour palette. Without the market research, it won’t know who your competitors are. The more context it has, the more tailored the output.

Q: Can I use VS Code instead of WebStorm?

Yes. WebStorm is my personal preference because of how it handles the terminal and file browser together, but everything we’re doing works fine in VS Code. The only difference is keyboard shortcuts and where the terminal panel lives.

Q: What if I don’t like what Claude generates even after a few rounds of iteration?

That’s a signal to be more specific in your prompts, not to give up. Take a screenshot of exactly what you don’t like, describe the specific problem (alignment, font, colour, layout), and ask Claude to address that one thing. Fixing everything in one prompt rarely works well — targeted, specific feedback gets better results.

Q: How do I know I’m ready for the next lesson?

If you have a working index.html that you can open in the browser and it looks like a real landing page — with a CTA, pricing section, and some social proof — you’re good. The email form won’t work yet; that’s what Module 4, Lesson 2 is for.

💬 Stuck? Come Talk to Us

Glossary

Claude Code: The command-line version of Claude, designed to operate directly inside your codebase. More powerful than Claude Desktop for development tasks because it can read, write, and run files in your project. (first introduced in Module 3, Lesson 3 - Installing Claude Code)

Frontend-design skill: A set of specialized instructions loaded from the .claude/skills/ folder that gives Claude expert knowledge about landing page design — typography, layout, conversion principles, and visual differentiation. (first used in Module 4, Lesson 1)

.sales folder: A project directory that holds your product documents (GTM, market research, etc.) so Claude has the right context when generating your landing page. (introduced in Module 4, Lesson 1)

MCP (Model Context Protocol): The integration layer that lets Claude connect to external tools and services. In this lesson, we’re using it to give Claude access to Vercel (used in a later lesson). (first introduced in Module 2, Lesson 4 - Generating the UX/UI Document)

Waitlist framing: The practice of positioning a pre-launch email capture as “early access” or “founding member” rather than “join the waitlist” — same mechanic, completely different experience for the user. (introduced in Module 4, Lesson 1)

Wordmark: A logo that uses only styled text — the company or product name — with no icon or symbol. Simpler to implement and often cleaner for early-stage products. (mentioned in Module 4, Lesson 1)

Micro-interactions: Small visual responses to user actions — like a button changing colour on hover, or an element animating into view as you scroll. They make a page feel polished and intentional. (referenced in Module 4, Lesson 1)