How to build a SaaS landing page with Claude Code

To build a good SaaS landing page with Claude Code, decide what the page has to say before deciding what it looks like. Give Claude the product’s audience, the one claim the page must land, a section plan where every section has a job, a specific visual direction with references, and real copy. Then build in sections and review each one in the browser at desktop and phone widths. Ask for “a landing page for my SaaS” and you’ll get the template everyone recognises: gradient hero, three feature cards, logo strip, pricing, FAQ.

Start from the argument, not the sections

A landing page is an argument with a single conclusion: this product is worth trying. Before any layout, write four things:

• Who it’s for, specifically enough that you could name one.
• The claim: what changes for them, in a sentence they’d say.
• The proof: what makes the claim believable (a demo, a real screenshot, a number you can stand behind).
• The action: one thing to do next, such as start a trial or join a waitlist.

If you’re unsure, let Claude interview you. Claude Code’s best practices suggest asking it to interview you before a larger piece of work and write a spec from the answers.

Plan the page hierarchy

Give every section a job in the argument. If a section has no job, cut it. A plan for a developer tool might look like this:

1. Hero: the claim, who it’s for, one action, and a real product visual.
2. Problem: the situation the reader recognises, in their words.
3. How it works: three steps, each with a product screenshot.
4. Proof: the strongest evidence you genuinely have. Skip testimonials you don’t have.
5. Objections: answers to the two or three reasons someone wouldn’t sign up.
6. Close: the action again, with one line of reassurance.

Notice what’s missing: a feature grid for its own sake, a logo wall with no logos, a pricing table before you have pricing. Honest omissions make a page more credible.

Define a visual direction

“Clean and modern” is the direction every generated page already has. A useful direction names a character and makes choices that rule things out:

• Character: “Editorial and calm, like a well-set technical book” or “dense and precise, like an instrument panel”.
• Type: a display face and a text face, or one family with clear weight contrast. A short type scale.
• Colour: a neutral base, one accent with a defined job, and what the accent is never used for.
• Imagery: real product screenshots, diagrams or none. Decide before generating, or you’ll get abstract blobs.
• Avoid list: the defaults you don’t want, such as gradient meshes, glassmorphism or emoji icons.

If you can’t choose, generate a few directions on purpose and compare them; see exploring multiple UI design directions.

Choose references with a reason

Two to four references are plenty, and each needs a stated purpose: one for the hero’s composition, one for the rhythm between sections, one for how screenshots are framed. Say what not to take, especially colours and illustrations. Our guide to giving Claude Code visual design references covers annotation in detail.

A reusable starting prompt

Adapt this to your product (the one below is fictional). It front-loads the decisions that otherwise get made by default, and it asks for a plan before any code.

We're building the landing page for Ledgerline, a reconciliation tool
for finance teams at 50 to 500 person companies.

Argument
- Audience: finance managers who close the books monthly in
  spreadsheets.
- Claim: "Close the month in days, not weeks."
- Proof we can show: a product screenshot of the matching view,
  and a 90-second demo video. No customer logos or testimonials yet.
- Action: "Book a demo". Secondary: "Watch the demo".

Sections (each has one job)
1. Hero: claim, audience line, both actions, product screenshot.
2. Problem: the month-end spreadsheet routine, 3 short lines.
3. How it works: connect, match, review. One screenshot each.
4. Security: plain answers to "where is our data" and "who can
   see it". Only facts from docs/security.md.
5. Close: the claim again and "Book a demo".

Visual direction
- Editorial and calm. Generous whitespace, strong type hierarchy.
- Type: a serif display face for headings, a neutral sans for
  body. Hero headline 56px desktop, 36px mobile.
- Colour: warm off-white background, near-black text, one deep
  green accent for primary buttons and key figures only.
- Imagery: only the real screenshots in public/screens/. Framed
  with a 1px border and soft shadow. No illustrations.
- Avoid: gradients, glass effects, icon grids, centred body text,
  more than two buttons in any section.

References (public/refs/)
- hero-ref.png: take the left-aligned hero with the screenshot
  overlapping the next section. Ignore its colours.
- rhythm-ref.png: take the section spacing and the way each
  section starts with a small label.

Build
- Next.js App Router, Tailwind, our components in src/components/ui.
- Copy is in content/landing.md. Use it exactly; don't invent copy.
- Fully responsive from 360px. Screenshots stack below text on
  mobile.

First, outline the page: section order, layout per section at
desktop and mobile, and which components you'll use. Wait for my
go-ahead before writing code.

Two instructions matter more than they look. “Use it exactly; don’t invent copy” keeps placeholder slogans out. “Only facts from docs/security.md” stops plausible but false claims from appearing on a page you’ll publish.

Build section by section

Approve the outline, then build the hero alone and review it before moving on. A page built in one pass is hard to review and tends to be uniformly average. Section by section, you can push each one to the standard you want and carry decisions forward.

Implementation details worth asking for explicitly:

• Fluid type for display sizes (for example with clamp()), with a sensible minimum on phones.
• Images with explicit dimensions and meaningful alt text.
• A constrained text measure, around 60 to 75 characters per line for body copy.
• Section spacing from your scale, larger between sections than within them.
• Semantic structure: one h1, sections with headings, buttons that are buttons and links that are links.

Refine typography and imagery

Most of a landing page’s quality lives in two places. For typography, check the hero headline’s line breaks at every width, tighten display tracking slightly, and make sure body text is comfortable rather than small. For imagery, real product screenshots beat illustrations, but only if they’re cropped to the part that proves the claim. Ask for crops, not full-window captures.

Browser QA and iteration

Review in the browser at desktop and a real phone width. Claude Code can do the first pass itself with the Chrome integration, and a Playwright setup makes the checks repeatable. Then review it yourself in this order:

1. Can someone tell who it’s for and what it claims within five seconds?
2. Is there exactly one obvious action per section?
3. Does every claim on the page have proof, and is every fact true?
4. Does the hero hold up at 360px wide?
5. Is anything there by default rather than by decision?

Iterate with narrow instructions (“reduce the hero subhead to one line; move the secondary action to a text link”) rather than regenerating. The guide to improving AI-generated UI has a full review pass.

Decide first, then build

A distinctive landing page comes from decisions made before the first prompt: the argument, the section jobs, the direction and the proof. Claude Code is fast at building those decisions and poor at making them for you. For a reusable version of the brief above, see how to write a design brief for AI coding agents.