Communitygithub.com

Waitlist Launch, step 1: launch landing page (Amplitude)

Plan and build a launch landing page that gets visitors to the wow moment fast: hero, supporting sections, one primary CTA, short forms, mobile-first and SEO basics, for pre-launch, launch day and after.

What is Waitlist Launch, step 1: launch landing page (Amplitude)?

Pre-launch Waitlist recipe, step 1 (page strategy), from amplitude/builder-skills. Before writing code or copy, the agent answers the key design questions, then lays out the page from hero through supporting sections to a footer CTA. It leans on developer-friendly patterns such as embedded playgrounds and real code, keeps one primary CTA with minimal form fields, covers SEO basics, and distinguishes temporary launch pages from permanent product pages across pre-launch, launch day and post-launch, including waitlist and urgency tactics.

Works with~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/amplitude/builder-skills/tree/HEAD/launch-skills/skills/launch-landing-page

Ask in your favorite AI

Open a new chat with this agent skill pre-loaded.

Documentation

Launch Landing Page

This skill helps design and build landing pages for product launches. A great landing page does two things: it communicates value fast, and it gets visitors to the "wow moment" as quickly as possible. Everything else is secondary.

The two design questions

Before writing a single line of copy or code, answer these:

  1. "How can we get the visitor to experience the 'wow' moment as quickly as possible?" The best landing pages let visitors use the product, not just read about it. For developer tools, this might mean an embedded playground. For SaaS, a live demo. For AI products, a widget that runs inference right on the page. The lower the friction between "I landed here" and "oh, this is great," the higher your conversion.

  2. "How can we make this page so well-designed that it becomes remarkable on its own?" A landing page that people screenshot and share on social media extends the launch beyond the initial push. This doesn't mean over-designed — it means thoughtful, polished, and distinctive.

Page structure

Hero section

This is the only section that matters for most visitors. 60-80% of visitors never scroll past it.

Components:

  • Headline — Your primary value prop from the messaging brief. One sentence, specific, benefit-focused. Should answer "what can I do with this?" not "what is this?"
  • Subheadline — 1-2 sentences expanding on the headline. Add specificity — who it's for, how it works, or a key proof point.
  • Primary CTA — One clear action. "Try it free," "Get started," "See it in action." Not two CTAs competing for attention.
  • Visual — Product screenshot, demo video, or interactive widget. Never a stock photo. Show the actual product doing the thing the headline promises.

Supporting sections (scroll depth)

Only include sections that earn their space. Each section should address a specific objection or expand on a secondary value prop.

Common sections (pick the ones that matter for this launch):

  • How it works — 3-step or visual walkthrough. Reduces "is this too complicated?" objection.
  • Key features/capabilities — 3-4 cards or columns. Each one a secondary value prop with a specific example or screenshot.
  • Social proof — Customer logos, quotes, usage stats, benchmark results. Reduces "is this legit?" objection.
  • Comparison — If you're entering a market with known alternatives, show a clear comparison. Be honest — cherry-picked comparisons erode trust.
  • Pricing — If pricing is a competitive advantage, surface it early. If it's complex or enterprise-focused, link to a separate pricing page.
  • Technical details — For developer and technical audiences. Code samples, API references, architecture diagrams.
  • FAQ — For objections that don't fit elsewhere. Keep it short — 4-6 questions max.

Footer CTA

Repeat the primary CTA at the bottom for visitors who scrolled the whole way. They're your most engaged audience — make it easy to convert.

Developer-first patterns

For technical products and developer tools, these patterns consistently convert well:

Reduce friction ruthlessly

The two biggest friction points for developers evaluating tools are cost and access. Address both on the landing page:

  • Free tier or trial with no credit card required
  • Instant access — no "request a demo" gate for individual users
  • Clear, transparent pricing visible on the page

Let them try before signing up

The most effective developer landing pages let visitors experience the product without creating an account. Examples:

  • Embedded code playground or REPL
  • API endpoint you can hit from the page
  • Interactive demo with real output
  • "Paste your data/code here and see results" widget

Show real code

Developers want to see what integration actually looks like. Include:

  • Install command (npm install, pip install, etc.)
  • Minimal working example (5-10 lines that do something useful)
  • Copy button on all code blocks

Lead with capabilities, not features

"Process 10,000 documents per second" is more compelling than "Distributed processing engine." Developers care about what they can build and at what scale.

SEO integration

A launch landing page is an SEO opportunity. The initial launch drives backlinks (from press, social, blog posts) that help the page rank long-term. Build for this from the start.

Naming for search

If this is a new product or feature, consider search volume when choosing the name. The name should match what your target audience actually searches for. "Speech to Text API" might get more search traffic than "Audio Transcription Service" — or vice versa. Use keyword research to decide.

On-page SEO basics

  • Title tag — Include the primary keyword. Keep under 60 characters.
  • Meta description — Compelling summary with keyword. 150-160 characters.
  • H1 — Should match or closely mirror the title tag.
  • Internal links — Link from your docs, blog, and other pages to this landing page. Link from this page to relevant docs and tutorials.
  • Page speed — Fast pages rank better and convert better. Optimize images, minimize JavaScript, use CDN.

Content for long-term ranking

The sections you add below the hero (how it works, features, FAQ) serve double duty as indexable content. Write them for humans first, but use the language your audience uses when searching.

Conversion optimization

One primary CTA

Every page has one primary action you want visitors to take. Everything else is secondary. If you're asking visitors to "Sign up," "Book a demo," "Join the waitlist," AND "Read the docs" with equal visual weight, you're asking them to choose — and many will choose to leave instead.

Reduce form fields

Every field you add to a signup form costs you conversions. Ask for the minimum needed to get them started. You can collect more information later.

Speed matters

Page load time directly affects conversion rate. Every second of load time costs roughly 7% of conversions. For landing pages specifically: lazy-load below-fold content, optimize hero images, minimize third-party scripts.

Mobile-first

40-60% of launch traffic often comes from mobile (people clicking links from social media on their phones). The hero section must work on a phone screen. Test the CTA button on mobile — can you tap it easily?

Launch-specific patterns

Landing pages for launches have constraints that evergreen product pages don't — they're time-sensitive, they need to convert a wave of traffic in a short window, and they often serve an audience that's hearing about the product for the first time.

Urgency and scarcity

For Tier 1 launches where you want to concentrate signups into a narrow window:

  • Launch pricing or early access window — "Free for the first 1,000 users" or "50% off for launch week" gives a concrete reason to act now instead of bookmarking. Display the deadline or remaining spots visibly.
  • Countdown timer — Use sparingly and only when the deadline is real (beta closes, pricing changes, access is limited). Fake urgency erodes trust.
  • Social proof in real-time — "1,247 developers signed up today" or a live counter. This signals momentum and reduces "am I the only one trying this?" hesitation.

Don't stack all of these. Pick one urgency mechanism that's genuine and make it prominent.

Waitlist flows

If the product isn't generally available yet, the landing page becomes a waitlist page. Waitlist pages convert at 2-5x the rate of standard signup pages because the scarcity is real.

  • Single field: Email only. Every additional field costs you waitlist signups.
  • Position feedback: "You're #847 on the waitlist" makes the signup feel concrete and gives you a re-engagement hook ("You're almost up!").
  • Referral mechanic (optional): "Move up the waitlist by sharing with friends." Only add this if you can actually fulfill on it — broken referral mechanics damage trust.
  • Set expectations: "We're letting in 200 users per week" or "Expect access within 2 weeks." Silence after signup kills interest.

Pre-launch, launch day, and post-launch states

A launch landing page isn't static — it should evolve through three phases:

Pre-launch (1-2 weeks before):

  • Teaser copy: what's coming, who it's for, when it launches
  • Waitlist or "notify me" signup
  • No product details beyond the primary value prop

Launch day:

  • Full page: hero, demo, features, social proof, CTA
  • Direct access: "Try it now" or "Get started free"
  • Launch video or demo embedded in hero
  • Any urgency mechanics active (countdown, launch pricing)

Post-launch (1 week after → permanent):

  • Remove time-sensitive elements (countdown, "just launched" language)
  • Add social proof that accumulated during launch (user count, testimonials, press logos)
  • Optimize for SEO: this is now a permanent product page
  • Update CTA to reflect the ongoing state ("Get started" vs. "Join the launch")

Plan for all three states before building. The pre-launch and post-launch states often get forgotten, leading to stale pages with expired countdowns or "just launched!" copy months after launch.

Launch page vs. permanent product page

For Tier 1 launches, consider building a dedicated launch page and a permanent product page:

  • Launch page — Optimized for the launch moment. Includes urgency mechanics, launch video, concentrated CTA. Temporary — plan to retire it.
  • Product page — The permanent home for this product/feature. Optimized for ongoing discovery and SEO. Replaces the launch page after the launch window closes (typically 1-2 weeks).

Transition plan: Before launch, decide when and how the launch page becomes the product page. The simplest approach: build the product page first, add a temporary launch-specific hero and urgency section on top, then remove those elements post-launch. This avoids building two separate pages.

For Tier 2 and below, update the existing product page. Don't create separate pages for features — they fragment your SEO.

Building the page

When actually implementing a landing page, keep in mind:

  • Start with copy, not design. Write all the text first based on the messaging brief. The copy determines the structure — not the other way around.
  • Use a proven layout. Hero → social proof → features → how it works → CTA. You can reorder, but don't reinvent the layout unless the product demands it.
  • Design for scanners. Most visitors scan, not read. Headlines, subheadlines, and visuals should tell the story even if body text is skipped.
  • Test the 5-second rule. Show someone the page for 5 seconds and ask what the product does. If they can't answer, the hero needs work.

Companion skills

  • launch-strategy — messaging brief that drives the page copy and structure
  • launch-video — the demo video and screenshots that go on the page
  • launch-blog-post — the post the page links to (and vice versa, for SEO)
  • launch-distribution — driving traffic to the page
  • launch-metrics — tracking page conversion rate and traffic sources via UTMs

Individual skills in this repo

This repo contains 20 individual skills — each has its own dedicated page.

amplitude/builder-skills

Performs deep analysis of a specific Amplitude chart to explain trends, anomalies, and likely drivers. Use when a metric looks unusual, investigating a spike or drop, or understanding the "why" behind numbers.

amplitude/builder-skills

Deeply analyze Amplitude dashboards by analyzing key charts, surfacing top areas for concern and takeaways, identify anomalies, then explain changes using customer feedback trends.

amplitude/builder-skills

Designs A/B tests with proper metrics and variants, analyzes running or completed experiments, and interprets results with statistical rigor. Use when setting up experiments, checking experiment status, analyzing results, or making ship decisions.

amplitude/builder-skills

Synthesizes customer feedback into actionable themes including feature requests, bugs, pain points, and praise. Use when planning product roadmap, understanding user sentiment, investigating specific issues, or preparing voice-of-customer reports.

amplitude/builder-skills

Analyze MCP server usage instrumented with Amplitude's MCP Analytics SDK: break usage and errors down by tool, read the rationales within each tool to see what callers are trying to do, and produce a prioritized write-up of actionable fixes. Use this skill whenever the user asks to understand how their MCP server is being used, what agents/users are trying to do with it, why tool calls are failing, what to fix or improve in their MCP server, or asks for an "MCP usage report", "tool error analysis", "intent analysis", "rationale clustering", or "MCP insights". Also trigger when the user mentions [MCP]-prefixed events, tool rationale, tool call errors, or just finished instrumenting their MCP server and wants to see what the data says. Requires the Amplitude MCP connector.

amplitude/builder-skills

Read lost deals and churned accounts from your CRM, extract reasons clustered by theme (missing features, pricing, competitors, UX), and write a prioritized weekly analysis with product improvement recommendations. Use before roadmap planning or to build the case for prioritizing retention work.

amplitude/builder-skills

Creates Amplitude charts from natural language descriptions, handling event selection, filters, groupings, and visualization choices. Use when you know what you want to measure but prefer not to build the chart manually.

amplitude/builder-skills

Guide an Amplitude user through building a custom agent by suggesting use cases grounded in their role and data, shaping the idea into a well-formed spec, and generating a ready-to-run Global Agent deeplink that creates it. Use to create, build, or set up a custom agent, automate a recurring analysis, or put a repeated report on a schedule.

amplitude/builder-skills

Builds comprehensive Amplitude dashboards from requirements or goals, organizing charts into logical sections with appropriate layouts. Use when creating a complete dashboard from scratch or assembling existing charts into a cohesive view.

amplitude/builder-skills

Monitors all active and recently completed experiments across Amplitude projects, triages them by importance, then runs deep analysis and reporting on the most impactful ones. Use when the user asks to "check on experiments", "experiment status", "experiment review", "what experiments are running", or wants a periodic experiment health report.

amplitude/builder-skills

Pull Intercom tickets and Slack support messages from the past 7 days, classify each signal, enrich with CRM data (ARR, plan, renewal), score by customer value and churn risk, and output a tiered priority report saved to Drive. Use when you need a fast, data-driven view of what support signals matter most.

amplitude/builder-skills

Use this skill whenever a user wants to improve existing pages on their website to get cited more by AI models — whether they say "our pages aren't getting cited", "improve this page for AI visibility", "which of our pages should we update", "make this article more cite-worthy", "our competitors are getting cited instead of us", "update our content for AI search", or any variation where the goal is improving an existing asset rather than creating something new. This skill pulls owned pages from AI Visibility, identifies which ones have citation potential but are underperforming, compares them against the external pages that are winning citations on the same topics, and produces section-level rewrites or a full-page update — then pushes the revision to the CMS as a draft. Trigger even if the user just says "help me get cited more" or "why is [competitor] getting cited instead of us".

amplitude/builder-skills

Use this skill whenever a user wants to win AI citations on prompts that competitors currently dominate — whether they say "competitors are getting cited instead of us", "we're losing on these prompts", "how do I outrank [competitor] in AI answers", "find prompts where we should be winning", "create content to beat [competitor]", or any variation where the goal is capturing AI share on prompts a competitor currently owns. This skill pulls competitor visibility data from AI Visibility, identifies the specific prompts where competitors win and Amplitude is absent, clusters them by intent, and produces targeted comparison pages, alternatives content, or rebuttal assets — then pushes drafts to CMS. Trigger on any mention of competitor, prompt hijack, outrank, or "why is [competitor] getting cited instead of us".

amplitude/builder-skills

Use this skill whenever a user wants to turn AI Visibility data into published content — whether they say "find content gaps", "what should we write about", "which topics have low visibility", "help me get cited by AI models", "create a blog post from our AI Visibility gaps", "we're losing to competitors on these prompts", or any variation where they want to go from AI visibility weakness to a draft article, landing page, or FAQ. This skill connects directly to Amplitude AI Visibility data (topics, prompts, visibility scores, citations, competitor data, full LLM responses and sources) and produces a publish-ready content brief plus full article draft. If the user mentions CMS (WordPress, Webflow, Contentful, Sanity, HubSpot, Ghost, Shopify), also trigger this skill to push the draft directly. Trigger even if they just say something vague like "what content should we create?" in an AI Visibility context.

amplitude/builder-skills

Use this skill whenever a user wants to test content variants before publishing to find which one will get cited most by AI models — whether they say "which version of this content will perform better", "test this article before we publish", "simulate how AI will respond to this content", "which angle should we use", "generate content variants and pick the winner", "run a simulation before publishing", or any variation where the goal is data-driven content selection rather than gut-feel publishing. This skill takes an identified content opportunity, generates 2–3 distinct variants with different angles or structures, scores them against actual AI model responses from AI Visibility, references the Simulate Changes feature for pre-publish validation, and produces a clear recommendation on which variant to publish — then pushes the winner to CMS. Trigger on any mention of "simulate", "test variants", "which performs better", "A/B content", or "before we publish".

amplitude/builder-skills

Use this skill whenever a user wants to understand which external sources are being cited by AI models on topics relevant to their brand, and wants to create content that will outrank those sources — whether they say "what sources are AI models citing", "why is [third-party site] being cited instead of us", "we want to be the definitive source on X", "build something that gets cited more than G2 or TechRadar", "create an authoritative asset", or any variation where the goal is producing a new reference asset (definition page, benchmark, methodology, glossary, comparison hub) designed to beat existing top-cited sources. This skill analyzes AI Visibility source data, reverse-engineers what makes top-cited pages authoritative, and produces a superior source asset — then pushes it to CMS as a draft. Trigger on any mention of "sources", "third-party citations", "authoritative content", "definitional pages", or "outrank".

amplitude/builder-skills

Instrument a Node/TypeScript MCP server with Amplitude's @amplitude/mcp-analytics SDK so tool calls, sessions, and rationale are tracked as Amplitude events. Use this skill whenever the user wants to add Amplitude analytics to their MCP server, mentions "MCP Analytics", "@amplitude/mcp-analytics", "instrument my MCP server", "track MCP tool calls", "add rationale to my MCP tools", or wants agent traffic (Claude, Cursor, ChatGPT) attributed back to Amplitude. Also use for adding UTM tagging to MCP-returned links, or for troubleshooting identity/user_id mismatches between MCP events and web/mobile Amplitude data.

amplitude/builder-skills

Instruments a pull request with Amplitude analytics that conform to the project's existing taxonomy. Reads the tracking plan via the Amplitude MCP server (events, properties, naming conventions), analyzes the PR diff to find the few user actions genuinely worth tracking, detects the codebase's SDK and tracking patterns, and adds instrumentation that matches both. Optionally (opt-in) stages new events and properties on an Amplitude tracking-plan branch for data-governance review. Use when asked to "instrument this PR", "add analytics to this change", "add tracking", "add Amplitude events", "instrument this feature", or "what should I track here".

amplitude/builder-skills

Diagnoses product health by cross-referencing Amplitude analytics (dashboards, charts, funnels, feedback, AI agent analytics), optionally Datadog (errors, latency, stack traces), and optionally Slack (qualitative feedback, bug reports, feature requests). Identifies what's broken, what's working, and what to do about it — with root causes, not just symptoms. Use when asked to "diagnose my product", "what's going on", "product health check", "what's broken", "where are users struggling", "give me a product diagnosis", or "what should I focus on".

amplitude/builder-skills

Summarizes B2B account health by analyzing usage patterns, engagement trends, risk signals, and expansion opportunities. Use for customer success reviews, renewal preparation, QBRs, or account prioritization.

Related Skills