PTENES
MODULE 5.7 · BUILD

🚀 Build: published landing page

Time to bring it all together. In modules 5.1 through 5.6, you learned why the output looks generic, built a design skill, learned the screenshot loop and its limits, used visual references responsibly, and organized your brand folder. This module is the project: leave here with a landing page (a single-page presentation — the “showcase” for a product, service, or idea) of yours, tested on your computer and actually published.

6
Topics
50
Minutes
Intermediate
Level
Build
Type
0 of 60%
1

🔀 The track funnel, converging into a single build

Let’s take a moment to look at the path you’ve taken. In 5.1, you saw the problem: asking for "make a beautiful website" without context produces something generic — a result with ~40% quality. From 5.2 to 5.6, you closed that gap piece by piece: a skill (a set of fixed instructions that teaches the process of design) for global design, the screenshot loop (the agent builds → takes a screenshot → compares → adjusts, repeating until it matches the reference), the limits of that loop (what it can’t see on its own), how to use a visual reference without copying another company’s brand, and a permanent brand folder with documented colors, fonts, and logo.

This module doesn’t teach any new pieces — it’s the moment to use all six together, on a real landing page, from the first prompt to the live link. That’s why it’s longer and more hands-on than the previous ones: you’ve already learned the theory; now it’s time to build.

5.2 Design skill 5.3 Screenshot loop 5.4 Loop limits 5.5 Reference + rebranding 5.6 Brand folder 5.1 Diagnosis (40%) 5.7 — Published landing page from 40% generic to ~60% solid, with a process

Caption: the five previous hands-on modules (plus the 5.1 assessment) feed into this build — each arrow is a piece you already have ready to use, not new theory.

💡 Main Concept

This module doesn’t introduce a new technique — it orchestrates the previous six into a single flow, from scratch to the published link.

  • •If any step below seems unfamiliar, go back to the relevant module before continuing.
  • •It’s okay to repeat a step (for example, run the screenshot loop more than once)—real builds are iterative.
2

🧩 The anatomy of a landing page that works

New here? One landing page ("landing page") is a single web page with one goal: help visitors quickly understand what you offer and take an action — buy, sign up, or get in touch. It's different from a full site with multiple pages; a landing page is intentionally streamlined. Before building one, it helps to know what makes an effective landing page so you can tell whether the agent's result is on the right track or just "pretty on the outside."

Hero

The first screenful — a strong headline, a supporting sentence, and the main button. In 3 seconds, visitors need to understand “what this is” and “what I get.”

Benefits

A section right below showing 3 to 5 concrete reasons to trust/buy — not technical features, but benefits (what changes for the person using it).

CTA

CTA (from the English call to action, “call to action”) is the button or link that prompts visitors to act—“Get started,” “Contact us.” A good landing page repeats its main CTA in at least 2 places (top and bottom).

Footer

Contact and trust information (address, social media, year) — small, but present. A landing page without a footer feels unfinished.

✓ Landing page that works

  • ✓One clear goal per page — it doesn’t try to sell three things at once
  • ✓CTA visible without much scrolling, repeated at the end
  • ✓Loads quickly — few heavy images, no excessive animation

✗ Landing page that doesn't work

  • ✗Generic hero like “Welcome to our website” that doesn’t say what it is
  • ✗CTA hidden way down the page, or no clear CTA
  • ✗Generic placeholder text (“lorem ipsum” or vague phrases like “we’re the best”)

💡 Practical Tip

Use this list of 4 sections as a visual checklist while reviewing the agent's result: if you can quickly point out the hero, benefits, CTA, and footer, the structure is right — even if the visual polish still needs adjustment in the screenshot loop (step 4, next).

3

🎯 Steps 1–3: goal, brand folder, and initial prompt

The entire build has 7 steps. The first three are preparation—without them, the agent starts with zero context and the result is generic again, exactly the problem from module 5.1.

1 Objective 2 brand_assets 3 Initial prompt 4 Screenshot loop 5 Manual review Localhost 6 7 Publish

Caption: the 7 steps in order — most of the time is spent on step 4 (screenshot loop), iterating; step 7 connects directly to module 5.8.

1

Define the landing page’s goal

Before opening the agent, write a single sentence: what it sells/announces/presents and to whom. Example: "landing page to attract people interested in a cooking course for beginners." Without this, the agent fills the gap with something generic.

2

Gather (or create) the brand_assets folder

If you already have one from module 5.6, just point to it. If not, use the 5.6 prompt to create one before continuing—skipping this step is the most common reason for getting a result without an identity.

3

Write the initial prompt, with the design skill active

The prompt combines the goal + brand folder + structure from the previous section (hero/benefits/CTA/footer) in a single request. See the copy-run block below.

Objective copy and paste into Claude Code — step 3

Ask for the first version of the landing page, with the design skill (5.2) active and the brand folder (5.6) as the source of truth, including the hero/benefits/CTA/footer structure.

Use a skill de design pra construir uma landing page (index.html, self-contained)
pra <descrição do objetivo: ex. "captar interessados num curso de culinária
pra iniciantes">.

Antes de escrever qualquer CSS, leia brand_assets/cores.md e
brand_assets/tipografia.md e siga exatamente a paleta e a fonte de lá.

Estrutura obrigatória:
1. Hero: título direto dizendo o que é + frase de apoio + botão CTA
   "<texto do seu CTA principal>"
2. Seção de benefícios: 3 a 4 cards com ícone + benefício concreto (não
   recurso técnico)
3. Seção de CTA reforçado, no meio ou perto do fim da página
4. Rodapé simples com <contato/redes/ano>

Depois de gerar, tire um screenshot e me mostre — vamos rodar o laço de
ajuste até bater com o padrão da marca.

✅ How to verify

The first screenshot should already use the exact colors of the cores.md (not an approximation) and have all 4 sections present. If any are missing, that’s a sign the agent skipped part of the prompt—ask it to revise before moving on to step 4.

4

🔁 Steps 4–5: the screenshot loop and manual review

New here? O screenshot loop (covered in detail in module 5.3) is the agent running a cycle: build → take a screenshot → compare it with what you asked for (or with a reference) → adjust what didn't match → take another screenshot → repeat. It's what turns "I guessed it looked good" into "I saw that it looked good."

Run this loop a few times in a row — usually 2 to 4 rounds are enough to resolve most spacing, alignment, and contrast adjustments. In each round, ask for something specific: “the hero button is too small; make it bigger,” “the space between the benefit cards is too tight.” Vague requests like “make it better” lead to random adjustments.

🔍 Inside

  • Typical run: screenshot → you point out 1-3 specific problems → agent adjusts only those points → new screenshot.
  • When to stop: when the screenshot matches what you had in mind and the 4 sections from topic 2 are present and clear.

By step 5, it’s time to be honest: even after the loop, there are things it doesn't fetch it on its own — exactly what module 5.4 warned about. Animation timing (too fast? too slow?), personal taste like "the spacing here seems a little wide, but I can't say why," and fine-tuning in the final stretch. That review is yours, with your own eyes, opening the actual page — not just looking at a static screenshot.

💡 Practical Tip

Set realistic expectations: following the entire process produces a much more solid result than the generic one from module 5.1—from “~40%” to somewhere near “~60%” professional polish. But it's not 100%: fine-tuning for personal taste, animation timing, and the final polish are still your job. That's not a flaw in the process; it's what remains for you to decide.

5

🖥️ Steps 6–7: test on localhost before publishing

New here? Localhost ("local host") means viewing the page running on your own computer, before it's published on the internet — usually at an address like http://localhost:3000 that only you (on your machine) can open. It’s the dress rehearsal before opening night: you browse, click links, and test on a phone and computer screen, all before anyone else can see it.

This step isn’t optional. A screenshot is always a little "frozen" — it doesn’t show whether a link is broken, whether the menu opens on a phone, or whether the CTA is actually clickable. Ask the agent to run the page locally, then open it yourself and check at least that the links work, the layout doesn’t break on a narrow screen (phone), and the main CTA actually goes somewhere (even if it’s just a temporary link for now).

✓ Complete localhost test

  • ✓It opened at a narrow mobile screen size, not just on a large monitor
  • ✓Clicked every link/button to confirm it responds
  • ✓Reloaded the page from scratch (didn’t just look at the result that was already loaded)

✗ "Tested" just by looking at the screenshot

  • ✗Only saw the loop’s screenshot, never opened the actual page
  • ✗Wasn’t tested on a narrow screen—the layout may break on a phone without warning
  • ✗Went straight to publishing without visiting localhost even once
Objective copy and paste into Claude Code — step 6

Ask the agent to run the landing page locally and give you the address so you can open it and test it yourself.

Suba esta landing page em localhost pra eu testar antes de publicar.
Me diga o endereço exato pra eu abrir no navegador.

Depois que eu confirmar que testei, some as próximas etapas (deploy/
publicação) — vamos seguir isso no próximo módulo, com calma.

✅ How to verify

You were able to open the local address in your browser, see the complete page (not a blank screen error), and click at least 2 interactive elements (a link or button) to confirm they respond.

With the local test approved, step 7 is publish ("deploy" — putting the page online at an address anyone on the internet can access, not just on your machine). The detailed rules for doing this properly — what to never automate on your own, when to ask for confirmation, and hosting precautions — are the entire subject of the next module, 5.8. Here, the milestone that matters is: your landing page is ready and tested, waiting only for the formal publishing step.

6

🧯 Common build errors and publishing checklist

To wrap up the build, let's take a look at the most common mistakes people make when going through this process for the first time—and the checklist that helps you avoid each one before moving on to module 5.8.

✓ Well-managed build

  • ✓Objective written before opening the agent, not decided “in the middle of the prompt”
  • ✓Existing brand folder explicitly specified in the initial prompt
  • ✓At least 2 rounds of the screenshot loop before calling it done
  • ✓Actually tested on localhost at two screen widths

✗ Rushed build

  • ✗Skipped the brand folder, "let’s see what comes out"
  • ✗Accepted the first loop result without any refinement rounds
  • ✗Published straight from the screenshot without opening localhost even once
  • ✗Waited for 100% polish before wrapping up — a build is never "perfect"; it just needs to be good enough

📋 Checklist before considering the build ready

  • ☐ The landing page's goal is written down and clear (what it sells/presents and for whom)
  • ☐ Folder brand_assets/ exists and was consulted in the prompt
  • ☐ All 4 basic sections are present: hero, benefits, CTA, footer
  • ☐ At least 2 rounds of the screenshot loop ran
  • ☐ You opened it on localhost and tested the links + narrow screen yourself
  • ☐ You're honest with yourself: you know it turned out ~60%, not 100% — and that's OK

Quick check (optional): Why test on localhost before publishing if the screenshot loop has already shown the page working?

📝 Exercise

Publish your own landing page: choose a real goal (it can be fictional, like an imaginary product — what matters is practicing the whole process), complete all 7 steps in this module from start to finish, and reach the point where the test passes on localhost. Save the repository/project folder link — you’ll use it directly in module 5.8 to complete the publication.

✅ Module Summary

✓
The 7 steps: goal → brand folder → initial prompt → screenshot loop → manual review → localhost → publish.
✓
Landing page anatomy: hero, benefits, CTA (repeated), footer.
✓
Result accuracy: the process goes from ~40% generic to ~60% solid — not 100%, and that’s fine.
✓
Localhost is required: a screenshot doesn’t replace testing the actual page before publishing.

Next module:

5.8 — Publishing rules: how to handle the final deploy properly, carefully, and without risky automatic actions.