waiting-list

Waiting-list portals

Use this skill to turn “we need a waitlist” into a truthful product promise, an appropriate system boundary, and a buildable delivery plan. A list of interested people, a fair order of service, a traffic gate, and a reservation are different things. Never let a polished landing page silently choose the semantics.

When to load

Load this skill when the user is designing, reviewing, implementing, or comparing a portal for early access, product launch demand, scarce goods, appointments, memberships, events, beta programs, or high-traffic admission.

When not to use

• For copy, visual design, SEO, or accessibility in isolation, use the relevant frontend or content skill and bring this skill in only for the list behavior.
• For a general API, database, email, security, or payment implementation, use the owning specialist skill; this skill supplies the waitlist-specific contract and failure modes.
• For a live waiting-room vendor or queue datastore, read its current official documentation. This skill is a design method, not a substitute for vendor runbooks or legal advice.
• For a standalone CRM migration or email/SMS campaign, use the owning integration skill. Load this skill when the CRM is a downstream of the waitlist's verified-contact lifecycle.

Core workflow

Default posture and marketer experience

For a new marketing waitlist, use one static HTML page, Alpine.js (CSP build), Vite packaging, custom CSS, TypeScript API functions on Vercel's Node.js runtime, and managed Neon Postgres. Use Twilio Verify codes for email (with SendGrid) and optional SMS verification; keep the CRM selectable through server-side runtime configuration. Avoid Python backends and Rails. Go or Rust are explicit alternatives for a campaign whose existing hosting or requirements warrant them. These are defaults, not reasons to replace an existing working integration.

Read references/default-stack.md before building or deploying. It defines the provider posture, Vercel limitations, repository shape, worker execution, and escape hatches. Read references/brand-and-marketer-workflow.md for all new portals: gather the campaign brief, brand guide, logos, reference images, and optional video; show a branded preview before connecting production. Use templates/campaign-brief.md as the plain-language intake. The agent fills technical records; do not ask a marketer to select an ORM, framework, retry algorithm, or database schema. For a premium, cinematic, motion-rich, or reference-led campaign, also read references/engagement-and-visual-system.md and record its relevant experience brief, fallback, performance, and visual-test decisions. Treat a reference site as a source of observable interaction principles, not as permission to copy its brand, assets, source, layout, scarcity language, or product claims. Use approved supplied assets or original image-generated artwork for campaign heroes, product scenes, and editorial illustration. Preview generated artwork for approval before publication. Do not substitute CSS shapes or gradients, inline SVG drawings, canvas sketches, emoji, ASCII, or icon collages for campaign artwork unless the user explicitly requests that aesthetic. Programmatic graphics remain appropriate when geometry is the information, such as charts, diagrams, controls, and status indicators. Use templates/campaign-config.example.json as a server-side configuration example; its unset production choices must be resolved before enabling live sends.