Northstar SaaS Waitlist and Local Application Draft

Implement Northstar Draft, a fictional SaaS waitlist landing page that lets a product lead inspect a launch checklist and prepare a local beta application draft. Return one standalone responsive HTML document with embedded CSS and JavaScript, no framework, font download, external image, API or network request. Deliver the working UI, not another brief. All records below are fictional examples; there is no AI analysis or real signup. Keep every input and receipt in memory only, cleared by reload.

Inputs and customization
Use a single configuration object for brand, headline, introduction and the three launch-mode records. Defaults: brand Northstar Draft; headline "A clearer plan for your next launch."; introduction "Choose a launch goal, inspect the work ahead, and prepare a beta application draft." State visibly near the first action: "Fictional product. Local interactive sample." State beside the form and receipt: "Nothing is sent. No beta place is reserved." Do not invent scarcity, signup counts, scores, testimonials, customers, dates, integrations, performance claims, pricing or availability. Do not infer readiness from text length. Buyers may replace the configuration with their own product and copy, then separately connect a real backend and consent policy; do not imply that connection exists here.

Use exactly these mode records, each with a title, purpose and three checklist items:
- pilot / Pilot conversion: "Understand what blocks a pilot from becoming a customer." Tasks: "Name the target pilot cohort"; "Record the approval blocker"; "Choose one conversion milestone". Output heading: "Pilot launch outline". Default goal: "Help pilot teams agree on one approval milestone."
- pricing / Packaging research: "Prepare research questions before changing packaging." Tasks: "Name the budget holder"; "List the outcome to investigate"; "Choose an interview question". Output heading: "Packaging research outline". Default goal: "Learn which outcome budget holders value most."
- trust / Trust review: "Make data and approval questions visible before a launch." Tasks: "Describe the data boundary"; "Name the approval owner"; "List one unresolved trust question". Output heading: "Trust review outline". Default goal: "Clarify the data boundary before inviting a pilot."
Start in Pilot conversion with zero tasks checked. Each mode retains its own three checkbox values and editable launch goal during the visit. Switching modes updates purpose, tasks, goal and count together; never carry a different mode's answers into the selected mode. Checkboxes only mark planning items considered, not launch readiness or real work completed. Show "0 of 3 planning items checked" computed from the selected mode. Provide a "Clear this checklist" button that clears only the current mode's boxes, leaves its goal unchanged and reveals "No planning items checked yet." Switching modes must leave a previously prepared receipt unchanged and visibly labeled as the prior draft.

Layout and visual constraints
Continue a restrained paper-and-green SaaS identity: warm paper #f6f5ee, near-white #fffdf7, deep ink #111816, muted text #49584f, green #007f5f and pale green #e7f2eb. Use system sans-serif for readable body and controls, with tabular/mono details on the draft summary. Compact header with Northstar Draft, "Explore the workflow" and "Prepare a draft" anchor links. A clear 58–76px desktop headline, a short introduction and one primary anchor lead into the interactive product board. Preserve strong spacing and rules; avoid gradients, particle animations, glass effects, decorative dashboards, invented metrics, testimonial blocks and repeated generic cards. No illustrative assets are needed: the working checklist is the product proof.
At desktop, a generous product board has a narrow vertical mode rail on the left and a clearly labeled checklist on the right. All three modes, the selected purpose, task labels, count and primary action should be readable in the first 900px-high viewport. Use real buttons with aria-pressed, rather than incomplete tab semantics. Below this, place a concise three-step explanation (Choose a goal, Review the checklist, Prepare a draft), then the draft form alongside a useful output area. Use open sections and horizontal rules rather than a grid of feature cards. Add two native details/summary FAQs answering what is saved and how to adapt the sample, plus a small footer with a back-to-top link. Include an unobtrusive "View source prompt" link to /prompts/landing-pages-landing-page-prompts-for-waitlist-pages-20260630-free/.
At 1024 and 768px allow wrapping; below 720px stack mode controls, checklist, form and output in that order. At 390 and 320px every label and action must remain readable without horizontal page scrolling. Use at least 16px input text and 44px control targets. Do not cover content with a fixed footer, source link or action. Long goals and email addresses wrap in the receipt. Include meaningful h1/h2 hierarchy, visible keyboard focus, high contrast, and text alongside every state indicator. Do not animate layout. Reduced-motion and Save-Data users get the same complete workflow without animation.

Application draft behavior
Provide a form headed "Prepare a beta application draft" with a required "Work email" input (type=email, max 120 characters, trim, ordinary non-space name@domain.tld validation) and a required "Launch goal" textarea (trimmed 10–180 characters). The selected mode's goal is editable here; changing it is retained for that mode. Email stays shared across modes. Give a small example hint so users can use a fictional address. Do not require real contact details or marketing consent for this local sample. Show the selected mode beside the submit action. The form action is "Prepare local draft", enabled whenever idle so validation can be discovered.
On submit, validate both fields, preserving invalid text. Show specific inline errors associated with their fields, set aria-invalid, and focus the first invalid field. Render user text with textContent, never interpolate it into HTML. A valid submission captures an immutable snapshot of selected mode, trimmed email, trimmed goal and exact checked task labels. It replaces any prior receipt only when completed. The snapshot must remain unchanged if fields or the selected mode later change.
Show "Preparing local draft…" for about 650ms with aria-busy and polite status. Disable repeat submission and all editable snapshot controls while pending, but leave reset/cancel available. Then show a receipt headed "Local application draft" with the mode-specific output heading, email, launch goal, exact selected checklist items (or "No planning items checked"), and "Nothing is sent. No beta place is reserved." Move keyboard focus to the receipt heading without trapping it. A successful draft is not a signup or reservation; no fake queue counter, readiness percentage, email confirmation or saved-to-cloud message.
Include a labeled "Simulate preparation failure" checkbox under an unobtrusive "Try recovery states" disclosure. It fails the next valid submission once and automatically unchecks. On failure keep the original snapshot available, show "Draft preparation failed. Your inputs are still here.", and offer "Try again" and "Cancel pending draft". Re-enable editing after failure. Try again must use the ORIGINAL failed snapshot even if the user changes mode, email, goal or checklist meanwhile; disable those controls during retry. A new explicit form submission replaces the failed snapshot with the new values. Clear stale error and success messages appropriately, and mark an existing receipt "Previous draft" when inputs differ from it.
"Copy draft" copies the displayed receipt's plain text exactly, never current unsent field edits. Report "Draft copied" only after clipboard success. If clipboard is unavailable or denied, show a labeled readonly textarea containing the exact receipt text, select/focus it and say "Copy unavailable. Select and copy the draft below." Hide stale copy success/fallback when a new receipt is generated. Do not report success on rejection.
"Reset sample" cancels all pending timers and failed snapshots, resets email, goals, checks, active mode and failure toggle, clears receipt/errors/fallback, announces "Sample reset" and restores focus to the first mode. "Cancel pending draft" cancels a pending or failed snapshot and keeps the current editable inputs; a canceled operation must never show delayed success. Reload returns to untouched defaults. Set data-preview-ready on the document once initial UI rendering finishes.

Acceptance checklist
1. Inspect desktop 1440×900, tablet 1024 and 768, mobile 390×844 and 320px for typography, spacing, readable hierarchy, contrast and no overflow. Verify working section/source links, FAQs and keyboard focus.
2. Check all three mode records and per-mode goal/checkbox retention. Counts derive from selected-mode tasks, and clearing one mode leaves the others intact. The zero-check state is useful and honest.
3. Submit empty and malformed inputs; verify inline errors, focus and safe rendering of literal HTML-like text. Valid drafts must preserve the exact submitted values, mode and checked tasks without implying delivery or signup.
4. Trigger duplicate submission, failure, editing after failure, retry, replacement submission, cancel and reset during preparation. Confirm retry uses its original snapshot and no canceled timer creates a receipt.
5. Copy a receipt after editing inputs and verify exact clipboard contents; deny clipboard and verify manual-copy text and truthful feedback. A new draft clears stale copy feedback.
6. Verify long input, reload, reduced-motion and Save-Data. No prototype network requests, analytics, storage, purchases or real messages. Record actual execution tool/model/date and only browser checks that were performed; never claim human review or compatibility with other models.