Dawnlist

A mock-up of the homepage, drawn from this design’s layout, palette and typefaces. A build follows the full prompt below.

Start from this templateRead the build prompt

Typefaces

Afacad is a soft, minimal sans that looks hopeful and quiet at 500 with tight tracking, suiting the starry near-black page and its cream accent.

• AfacadHeadings: headline 48px / 36px 500 at -0.05em, section heading 28px 400
• AfacadBody: body 16px/1.5 400, button 14px 500, pill 14px

Another design for the same product as Queueline, so the gallery lists it there. A dark pre-launch waitlist page that collects names and emails for a launch.

Patterns

• starfield particle backdrop
• coming-soon pill above logo
• stacked two-field form with full-width button
• social contact line
• 3x2 logo tile grid
• corner utility buttons
• footer credit line

States it is designed for

• idle
• submitting
• success
• duplicate email (friendly message)
• validation errors (empty name, invalid email)
• rate limited
• email send failed (still saved, notice)

Who it is for

• indie makers
• early-stage founders
• developer-tool launches

Layout

1. Corner buttons: small icon button top-left (open signup sheet) and top-right (source link)
2. Centered column (480px): coming-soon pill, pale yellow logo mark, 48px two-line headline, two-line subtext
3. Form: name input, email input, full-width dark button with pale yellow label
4. Contact line: 'questions? reach out' with two icon links
5. Powered-by section: heading, subtext, 3x2 grid of logo tiles (2 columns on mobile)
6. Footer: hairline top border and a credit line
7. Background: fine star particles drifting

Palette

Nocturnal, hopeful, minimal. A warm cream accent on near-black with a sprinkle of stars.

• page background#09090b
• logo tile / input fill#18181b
• button / pill fill#27272a
• primary text#fafafa
• secondary text#a1a1aa
• brand accent (logo, button label)#fef9c3
• pill text (lifted from the observed 45% cream)#918f78
• input border#64646f
• particle dots#fef08a

Every checked pair, measured again

As vibld’s tokens

The palette on the fifteen colour tokens vibld styles a project with, each text colour on the fill it is read on. Marked tokens are solved from the palette, because no swatch held that role at 4.5:1.

• background
• card
• muted
• primary
• secondary
• accent
• destructive *

Type scale

Display

Afacad 500, 48px/1.0, tracking -0.05em (36px mobile)

Body

Afacad 400, 16px/1.5

Button 14px 500 cream; section heading 28px 400; pill 14px.

Spacing and imagery

Centered narrow column in a full-bleed dark page; inputs 40px tall; 12px gaps; radius 6px on inputs and buttons, full on pill; logo tiles 72px tall radius 6px with 1px border.

Fine drifting particle stars; a simple two-leaf logo mark in pale yellow; monochrome placeholder logos in tiles.

Components

• CornerIconButton
• ComingSoonPill
• LogoMark
• WaitlistForm (name, email)
• ContactLine
• LogoTileGrid
• Footer
• Toast
• ParticleBackground

Interactions

• Submit shows spinner; success replaces the form with a thank-you message and confetti-free check
• Particles drift slowly; static under reduced motion
• Logo tiles brighten border on hover
• Errors appear below each field and focus the first invalid one

Data

• Signup{id, name, email, status (pending|welcomed), source, created_at}
• Showcase{name, logo, href, order}

Guardrails

Experience

• Ask for name and email only
• Keep the form above the fold at 390px
• Success message states when to expect news
• Use neutral placeholder marks in the showcase until real partners agree
• Corner buttons have tooltips explaining them

Accessibility

• Inputs have labels (visually hidden allowed) not just placeholders
• Pill text is lifted to meet 4.5:1 on its fill
• Particles are aria-hidden and paused under reduced motion
• Icon-only links have accessible names
• Button label meets 4.5:1 on dark fill
• Focus ring 2px cream with offset

Security

• No client access to signups (RLS deny); inserts through an Edge Function
• Rate-limit by IP with a sliding window; honeypot field
• Validate and normalize with zod; cap name length
• Transactional email key server-only; send from a verified domain
• Admin review via an authenticated view restricted to an admin role

Build prompt

The baseline every prompt in the catalog assumes, then this design’s own ten sections, from goal to guardrails.

Copy the baseline and build prompt

### How to use these prompts
Paste an entry's build prompt into your coding agent as the first message. Each prompt names its own stack, tokens and acceptance criteria; the rules below apply to all of them and can be prepended once per project.

### Engineering baseline
- TypeScript strict mode, no `any`, small typed components, feature folders, and one source of truth for design tokens (CSS variables consumed by Tailwind).
- Validate every input with a shared zod schema on the client and again on the server or edge function. Never trust client-side checks alone.
- Show loading, empty and error states for every async view. Surface errors in plain language with a retry, and log details to the console in development only.
- Keep secrets out of the bundle. Only publishable keys (for example a Supabase anon key) belong in client code; service-role keys, API keys and webhooks live in server or edge-function environment variables.

### Data and auth baseline (full-stack entries)
- Enable Row Level Security on every table before inserting data. Default-deny, then add owner-scoped policies (`auth.uid() = user_id`) and explicit role checks for admin views.
- Store roles in a separate table checked by a security-definer function, never in a user-editable profile field.
- Upload files to private storage buckets with size and MIME limits, and serve them through signed URLs.
- Rate-limit public endpoints (forms, auth, AI calls) and add a honeypot field or captcha to anonymous forms.
- Take payments through a hosted checkout and verify webhooks by signature. Never handle raw card data.

### Accessibility and UX baseline
- Target WCAG 2.2 AA: 4.5:1 contrast for normal text and 3:1 for large text, input borders, focus rings and meaningful icons or chart lines. Every palette in this catalog lists its verified pairs; re-check with a contrast tool after any colour change.
- Keep body text at 16px or larger with 1.5 line height, nothing below 12px, no light weights under 24px, and uppercase only for short labels.
- Give every interactive element a visible focus ring, full keyboard support, semantic landmarks, labelled form fields, and alt text on meaningful images.
- Respect `prefers-reduced-motion` for every animation. Give drag-and-drop and carousels keyboard and button alternatives.
- Build mobile-first and test at 375px, 768px and 1280px.

### Content guardrails
- Use original copy, fictional sample data and placeholder or licensed imagery. Do not reuse another product's name, logo, screenshots or marketing text.
- Label demo testimonials and metrics as samples. Collect the minimum personal data the feature needs.

### SaaS screen baseline
- Design every screen for its full set of states: first-run empty, loading skeleton, partial data, error with retry, permission-denied, and success feedback. Each entry lists the states its screen needs.
- Keep destructive actions (delete, revoke, downgrade, remove member) behind a confirmation that names the object, and prefer undo over a second dialog where the action is reversible.
- Enforce authorisation on the server for every action a screen exposes. Hiding a button is not access control; check the role again in the API or RLS policy.
- Never show secrets (API keys, tokens) in full after creation. Show them once, then mask them, and offer rotate and revoke.
- Keep the app shell (navigation, workspace switcher, account menu) consistent across screens, and preserve filters, sort and scroll position when the user navigates back.

### Goal
Build **Dawnlist**, a dark pre-launch waitlist page that collects a name and email, sends a welcome email, and shows the tools behind the product in a neat logo grid. Signups must be safe from spam and easy for the team to review.

### Stack
Next.js (App Router), React, TypeScript, Tailwind CSS, shadcn/ui, react-hook-form + zod. Supabase Postgres for signups with an Edge Function for inserts and rate limiting; a transactional email service for the welcome email. (The original used a note-taking database as CMS; use a Supabase table instead.)

### Pages & layout
1. **/**: small icon buttons in the top corners. Centered 480px column: "Coming soon" pill, pale yellow logo mark, 48px two-line headline, two-line muted subtext, name field, email field, full-width dark "Join the waitlist" button with cream label, a contact line with two icon links. Below: "Built with" heading, one-line subtext, 3x2 grid of logo tiles using neutral placeholder marks. Footer with a top hairline and credit line. Star particles drift across the page.
2. **/admin** (authenticated, admin role only): table of signups with search and CSV export.
Mobile: headline 36px, logo grid 2 columns, corner buttons remain 36px.

### Design system
- Colors: `--canvas: #09090b` (page background), `--surface: #18181b` (logo tile / input fill), `--surface-2: #27272a` (button / pill fill), `--fg: #fafafa` (primary text), `--muted: #a1a1aa` (secondary text), `--cream: #fef9c3` (brand accent (logo, button label)), `--pill-fg: #918f78` (pill text (lifted from the observed 45% cream)), `--border: #64646f` (input border), `--star: #fef08a` (particle dots).
- Fonts: Afacad (Google Fonts) 500 headline 48px/1.0 with -0.05em tracking (36px mobile), 400 body 16px/1.5, button 14px 500, section heading 28px 400.
- Spacing: 4px base; 12px between fields; 48px between sections; tile gap 16px.
- Radius: 6px inputs, buttons and tiles; full pill.
- Shadows: none; 1px borders `#64646f` on inputs and tiles.
- Motion: particles drift 20-40s; submit spinner; reduced motion freezes particles.

### Components & interactions
CornerIconButton (tooltip), ComingSoonPill, LogoMark, WaitlistForm (idle, submitting, success, duplicate, invalid, rate-limited, email-failed), ContactLine, LogoTileGrid, Footer, Toast, ParticleBackground (single canvas).

### Data & state
`signups(id, name, email unique, status, source, created_at)` and a static `showcase` list. The Edge Function validates, rate-limits, inserts, and sends the welcome email, marking `status = welcomed` on success. Form state is local.

### Accessibility
Every input has a label; errors are linked with `aria-describedby` and announced. The observed pill text (cream at 45% opacity) fails, so use solid `#918f78`. Particles are decorative. Icon links have names. Focus ring 2px `#fef9c3`.
Verified contrast: body text: #fafafa on #09090b = 19.06:1; muted text: #a1a1aa on #09090b = 7.76:1; button label: #fef9c3 on #27272a = 13.87:1; pill text: #918f78 on #27272a = 4.54:1; input text: #fafafa on #18181b = 16.97:1; input border: #64646f on #09090b = 3.41:1; focus ring: #fef9c3 on #09090b = 18.52:1.

### Security
- RLS denies anon select/insert on `signups`; the Edge Function uses the service role. Admin select via a policy checking an `admin` role claim.
- Sliding-window rate limit per IP; honeypot; zod validation (name 1-80 chars, normalized email).
- Email key server-only; verified sending domain; include an unsubscribe link.

### Performance & SEO
Static page with one client island for the form and one canvas. Logo tiles are inline SVG placeholders. Title, description and OG image; /admin noindex.

### Guardrails
- Invent product name and copy; no real brand logos in the grid.
- Never show another person's signup data on the public page.
- Acceptance criteria: (1) valid signup saves and sends a welcome email; (2) duplicate email returns a friendly message; (3) spam bursts are throttled; (4) admin sees signups, anon cannot; (5) all contrast pairs pass including the pill.

Open the builderAll templatesThis palette on its own