How to build a landing page with AI (owned templates path)

Sandboxed page generators are excellent at one job: turn a short brief into a hosted preview before the week ends. That is a real speed win for a waitlist sketch or a launch mock. The failure mode starts later — when the page becomes the buyer-facing surface you keep editing for months, and every copy tweak still costs a credit, lives in a vendor workspace, or arrives as an export with no project memory beside the sections.

An owned landing page answers a narrower build question. You already use a filesystem agent in Cursor or Claude Code. You need hero, proof, pricing, and a closing ask that look finished on day one — then you need those sections to stay ordinary source under your org. This post is a how-to for that build order: sections first, then CTA and light analytics you control, then agent docs that keep the next session honest. It is not a kit catalog tour — for what the landing-templates product ships and when to buy the SKU, see Landing templates kit: own the marketing repo your agents extend.

What you are building (and what you are not)

A landing page in this lane is a single marketing surface: waitlist, product teaser, changelog launch, or pre-order story. It is not a full-stack product kit. Auth, Postgres tenancy, and billing belong in the $99 kits. The marketing page's job is narrower and still durable: tell one story, collect one action, and stay editable without renting the system of record.

OTF sells fifteen single-page marketing templates on https://otf-kit.dev/templates, priced from $9 on https://otf-kit.dev/pricing, with live demos such as https://volt.otf-kit.dev, https://aura.otf-kit.dev, and https://gallery.otf-kit.dev. Each purchase follows the same ownership path as other kits: Stripe checkout, private GitHub invite, clone, local run, deploy to a domain you control. The free component layer those pages sit on is https://github.com/otf-kit/sdk.

Public claims that matter for this how-to:

• A finished section map per template — hero, features or proof, pricing or specs, journal or press, closing CTA — not a blank section kit
• Multiple color themes and imagery that holds on phone and desktop
• Agent configs (CLAUDE.md, .cursorrules, companion prompts) beside the page source
• Commercial use for one client project on the individual template SKU; Bundle buyers get all fifteen
• One-time payment; editable source stays after purchase

This article assumes you already chose "own the page." The rest is the assembly path agents should follow so the first session does not become a redesign from a blank chat.

Owned landing versus a throwaway generator page

Stay on a sandboxed generator when the artifact you need this week is a hosted preview URL, the team's daily loop is chat inside that product, and export or Git sync is enough for review. Prefer an owned landing when most of these flip true:

• Maintenance will happen on disk in Cursor or Claude Code, not only in a browser IDE
• The page is a buyer-facing waitlist, product, changelog, or launch surface you intend to keep for months
• Headline, CTA label, and section order must version with the rest of your product tree
• You refuse to pay a credit meter for every copy pass after the first draft
• Deploy target and DNS must sit on a domain you already operate

Generators remain useful. Many teams keep a sandboxed mock for pitch decks while the live waitlist lives in a cloned template. Buy (or scaffold from) an owned template when the marketing page becomes part of the repo agents reopen every week — the same ownership thesis as the kit tour post, applied here as a build sequence rather than a SKU walkthrough.

Sections first: map the story before you rewrite copy

Anthropic's Claude Code docs state the constraint plainly: each session starts with a fresh context window, and project CLAUDE.md files are how you give the agent persistent architecture, commands, and conventions. OTF's AI tool overview documents the same pattern across kits: agent files ship beside the source so opening the repo does not require re-explaining the stack. For a landing page, that handoff starts at sections, not typography debates.

A practical mental model of what you are assembling:

landing-template/
  src/
    sections/          # Hero, proof, features, pricing/specs, journal, CTA, footer
    components/        # Template-local pieces
  CLAUDE.md            # What this page is; how to customize
  .cursorrules         # Cursor-facing mirror of conventions
  AGENTS.md            # Universal agent notes when present
  ai/prompts/          # Tested recipes: swap copy, add section, recolor
  README.md            # Setup, customize, deploy

Build rule one: keep the section order the template already encodes unless the story truly needs a new block. Agents love to invent a second hero or a novelty pricing layout. That burns the polish you paid for. Point the agent at the section map first:

Read CLAUDE.md and list the section components in order.
Do not redesign the page. Confirm which section owns:
1) primary headline + supporting line
2) proof or feature grid
3) pricing / specs / collection (whichever this template uses)
4) closing CTA
Then stop and wait for the swap list.

Only after that inventory should you hand over copy. Swap headline, subcopy, and CTA labels in place. Replace image paths only where the template marks them. Recolor through the theme tokens the README names — do not invent a parallel palette in a one-off CSS dump. The free SDK at https://github.com/otf-kit/sdk is the shared UI layer; your job in session one is to put your story into the existing sections, not to interview the model about design systems.

If you need a new section (for example a FAQ under pricing), add it as a sibling in sections/, wire it into the page shell the same way neighboring sections mount, and document the addition in CLAUDE.md so the next session does not delete it as "unused." Bounded extension beats a chat-driven redesign.

Then CTA and light analytics you actually keep

A landing page without a clear ask is a brochure. The closing CTA — waitlist email, start-free, book-a-demo, pre-order, reserve — is the product outcome of the section map. Treat it as a first-class seam:

1. One primary action on the hero and the closing block. Secondary links (docs, GitHub, pricing detail) stay quieter. Agents often duplicate CTAs with conflicting labels; fix that before you ship.
2. Form or checkout ownership — if the waitlist posts to your endpoint or a form provider you chose, keep that wiring in the repo. Do not leave "connect later" placeholders that only work inside a generator's publish target.
3. Success and failure states — confirmation copy and error copy live beside the CTA component so the next agent session can edit them without hunting a vendor dashboard.

Light analytics belongs in the same pass as the CTA, not as a week-two afterthought. You do not need a full product analytics kit on a marketing page. You do need events you can trust when you change headline variants:

• Page view on the landing route
• Primary CTA click (and which placement: hero vs footer)
• Form submit success / validation failure
• Optional outbound clicks that matter to the funnel

Prefer a small client snippet or tag you own in source, with IDs named in CLAUDE.md, over a black-box "insights" panel that only exists while the page stays on a rented host. If you later move the page between hosts, the event names should still mean the same thing in your notes. Storefront templates already aim at custom-domain deploy via the included ship path; analytics that travels with the repo matches that ownership model.

Read the CTA component and any analytics helpers.
1) Keep a single primary CTA label across hero and closing section
2) Wire submit to the endpoint documented in README (no new third-party form host unless we choose one)
3) Emit named events: landing_view, cta_click, waitlist_submit — document names in CLAUDE.md
4) Do not add a second analytics vendor beside the one we already use

That is the CTA/analytics step: make the ask real, then make the measurement real, both as files agents can diff.

Agent docs last in the loop — first every later session

The build order is sections → CTA/analytics → agent docs, but agent docs are what make the loop repeatable. After the first honest pass, every later change should start from the shipped memory files, not from a blank "rebuild this page" prompt.

Practical handoff after purchase (or after you clone a template you already own):

git clone <your-private-landing-template-repo>
cd <template>
# install with the package manager the README names
bun install   # or npm install / pnpm install per README
bun dev       # local preview

Open the repo in Cursor or Claude Code. Point the agent at docs before copy:

Read CLAUDE.md, .cursorrules, and ai/prompts/. Then:
1) Keep section order and spacing conventions
2) Replace hero headline, supporting line, and primary CTA for our waitlist
3) Swap product imagery paths only where marked
4) Confirm waitlist submit + landing_view / cta_click events still fire
5) Do not invent a new design system or a second analytics vendor

Treat ai/prompts/ as recipes for swap-copy, add-section, and recolor jobs. Storefront copy notes AI configs across Cursor, Claude, and related tools; those files are the product surface that separates an owned template from a throwaway generator export. Update CLAUDE.md when you add a section or rename an event — otherwise the next session will fight your last session.

When local preview matches the story, ship static output with the README deploy path. OTF documents a custom-domain helper for kits that use the included ship scripts:

bash scripts/setup-custom-domain.sh \
  --domain your-launch.com

Use the template README for the exact host path. Outcome that matters: the live URL serves files from your repository, CTA and events are in source, and the next headline test is another agent session on the same tree — no credit balance required to change a string.

Handoff checklist: sections to CTA to agents

The loop you own has four steps:

1. Sections — inventory the map; swap copy in place; add a sibling section only when the story needs it; document the addition.
2. CTA — one primary ask; real submit path; success and error copy in the component.
3. Analytics — named events in source; IDs recorded in CLAUDE.md; no second vendor by accident.
4. Agents — every later change starts from agent docs; deploy from the clone you control.

That sequence is the how-to. The kit tour post covers SKU, previews, and the buy-versus-sandbox decision in product language. This post assumes the decision and walks the assembly path.

What "owned" means for a landing page you keep editing

Ownership here is operational, not a slogan:

1. Source of record — sections, CTA wiring, and event names live in Git under your org.
2. Agent continuity — CLAUDE.md, .cursorrules, and ai/prompts/ reload every session.
3. Edit path — Cursor and Claude Code change files on disk; you are not paying a meter per tweak.
4. Host choice — static marketing output can sit on DNS you already operate.
5. Commercial rights — individual template SKU includes commercial use for one client project; Bundle includes all fifteen. Confirm limits on https://otf-kit.dev/pricing.

Compare that to the throwaway generator loop: chat → preview → publish → pay credits for the next pass → maybe export when engineering asks. Export can move files. It does not automatically move a durable section map, CTA contract, or event vocabulary. The owned path inverts the order: sections and agent docs arrive first; agents edit second.

Landing templates are the $9 marketing lane on https://otf-kit.dev — waitlist and launch surfaces that pair with the free SDK and, later, with product kits when you need auth, data, and billing. For the product how-to on what ships and when to prefer the kit over chat-to-preview tools, read /blog/landing-templates-kit-own-the-repo. If you already need an owned page you will keep editing in Cursor, start on https://otf-kit.dev/templates, open a live demo, and buy the template that matches the story you are shipping — then follow sections → CTA/analytics → agent docs on the first day.

Sources

OTF templates catalog (landing templates lineup and live demos): https://otf-kit.dev/templates

OTF pricing (Landing Template $9 SKU, Bundle inclusion, commercial notes): https://otf-kit.dev/pricing

OTF AI tool integration (kit agent configs: CLAUDE.md, .cursorrules, AGENTS.md): https://otf-kit.dev/docs/ai-tools/overview

OTF templates overview (purchase → GitHub invite → clone → deploy path): https://otf-kit.dev/docs/templates/overview

Anthropic Claude Code memory (CLAUDE.md as persistent project instructions across sessions): https://docs.anthropic.com/en/docs/claude-code/memory

OTF free SDK: https://github.com/otf-kit/sdk

OTF site: https://otf-kit.dev

Live landing template example (Volt): https://volt.otf-kit.dev

Related internal post (kit product tour / own-the-repo): https://otf-kit.dev/blog/landing-templates-kit-own-the-repo