Dimeplan

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

Barlow's slightly rounded, low-contrast grotesk has a stark 800 that looks developer-plain on pure black.

• BarlowHeadings: heading 60px / 36px 800, prices 48px 800 tabular, plan names 24px 600
• BarlowBody: body 16px/1.5 400, subtitle 24px, caption 12px uppercase +0.3em

Patterns

• centered pricing header
• segmented control monthly/yearly
• flex-wrapping plan cards centred
• accent-outlined featured plan
• full-width white subscribe button
• letter-spaced 'brought to you by' caption with logo row
• multi-column footer

States it is designed for

• no products synced (empty state explaining setup)
• loading plan skeletons
• subscribe while already subscribed (switch to manage)
• checkout cancelled (back on pricing with notice)
• account update validation errors
• portal link error with retry

Who it is for

• developers adding paid tiers
• side-project builders
• teams prototyping pricing

Layout

1. Header: circle logo + 'Pricing' link left, 'Sign in' right
2. Pricing hero: centered 60px heading, two-line 24px subtitle, monthly/yearly segmented control
3. Plan grid: cards 240px wide, centred and wrapping (3 + 1 on desktop), featured card with pink outline; one column on mobile
4. Caption: small uppercase spaced label + row of generic tech marks
5. Footer: dark grey band with logo, link columns (product, legal), social icon; bottom bar with copyright
6. Account page: three stacked cards (plan, name, email) each with a footer action row

Palette

Stark, confident, developer-plain. Pure black with one pink outline to mark the recommended plan.

• page background#000000
• plan card / footer#18181b
• segmented thumb#3f3f46
• primary text#ffffff
• subtitle text#e4e4e7
• secondary text#a1a1aa
• subscribe button fill#ffffff
• subscribe button label#27272a
• featured plan outline#ec4899
• input border#71717a

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

Barlow 800, 60px/1.0 desktop and 36px mobile

Body

Barlow 400, 16px/1.5; subtitle 24px/1.35

Observed a system sans; Barlow stands in for it. Plan names 24px 600, prices 48px 800, caption 12px uppercase with 0.3em tracking.

Spacing and imagery

Sparse; 1100px container; cards 24px padding, radius 6px; buttons radius 2px; no shadows; 1px outlines only on the featured card.

No imagery beyond a row of monochrome tech logos (use generic placeholder marks) and a simple circle logo.

Components

• SiteHeader
• SegmentedControl (Monthly / Yearly)
• PlanCard
• SubscribeButton
• LogoCaptionRow
• SiteFooter
• AccountCard (with footer action)
• Toast

Interactions

• Toggle switches plan prices; plans without a yearly price hide or show 'monthly only'
• Subscribe shows a spinner, then redirects to hosted checkout
• Signed-out subscribe goes to sign-in and returns to pricing
• Account cards save inline and show a success toast
• Manage subscription opens the billing portal

Data

• Product{id, active, name, description, image, metadata}
• Price{id, product_id, active, unit_amount, currency, type (one_time|recurring), interval (day|week|month|year), trial_days}
• Customer{id (user id), provider_customer_id}
• Subscription{id, user_id, status (trialing|active|canceled|incomplete|past_due|unpaid|paused), price_id, quantity, cancel_at_period_end, current_period_end}
• User{id, full_name, avatar_url, billing_address, payment_method}

Guardrails

Experience

• Sync plans from the billing provider; never hard-code prices in the UI
• Mark one plan as featured with outline and label, not size
• If the user is subscribed, the pricing CTA becomes 'Manage'
• Keep the account page to three focused cards
• State the trial length on the button area when a trial exists

Accessibility

• Segmented control is a radiogroup
• Featured plan has a text label ('Recommended') in addition to the outline
• Subscribe buttons include the plan name in their accessible name
• Caption uppercase text is short with wide tracking
• Footer headings are real headings; social link has a label
• Focus ring 2px white with offset

Security

• RLS: products and prices public read; customers no client access; subscriptions and users readable only by owner (id/user_id = auth.uid())
• Webhook handler verifies signatures and upserts products, prices and subscriptions with the service role
• Checkout session created on the server from a validated price id; rate-limited
• Validate account updates with zod; email change requires confirmation

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 **Dimeplan**, a minimal subscription-billing starter. A pure-black pricing page lists plans synced from the billing provider, a monthly/yearly toggle switches prices, and Subscribe sends the user to a hosted checkout. Signed-in users get an account page to see their plan, change their name and email, and open the billing portal.

### Stack
Next.js (App Router), React, TypeScript, Tailwind CSS, shadcn/ui (Radix), lucide-react, react-hook-form + zod. Supabase Auth (email + OAuth) and Postgres; a webhook route or Edge Function keeps products, prices and subscriptions in sync from a hosted checkout provider.

### Pages & layout
1. **/** (pricing): header with circle logo and "Pricing" link left, "Sign in" right. Centered 60px heading "Pricing plans" (write your own), 24px two-line subtitle, segmented control (Monthly billing / Yearly billing). Plan cards (name, one-line description, big price with "/month", full-width white Subscribe button) centred and wrapping; the featured one gets a pink outline and a "Recommended" label. Small uppercase caption and a row of generic tech marks. Footer band with logo, link columns and a social icon; copyright bar.
2. **/signin**: email/password or magic link, OAuth option.
3. **/account**: three stacked cards: Your plan (name, price, "Manage subscription"), Your name (input + Save), Your email (input + Update; confirmation email).
Mobile: heading 36px, cards full width, footer columns stack.

### Design system
- Colors: `--canvas: #000000` (page background), `--surface: #18181b` (plan card / footer), `--surface-2: #3f3f46` (segmented thumb), `--fg: #ffffff` (primary text), `--sub: #e4e4e7` (subtitle text), `--muted: #a1a1aa` (secondary text), `--btn: #ffffff` (subscribe button fill), `--btn-fg: #27272a` (subscribe button label), `--featured: #ec4899` (featured plan outline), `--border: #71717a` (input border).
- Fonts: Barlow 800 heading 60px/1.0 (36px mobile), 600 plan names 24px, 800 prices 48px with tabular numerals, 400 body 16px/1.5, 24px subtitle; caption 12px uppercase with 0.3em tracking.
- Spacing: 4px base; card padding 24px; 24px gap; 96px section spacing.
- Radius: 6px cards and segmented control, 2px buttons.
- Shadows: none; featured plan uses a 1px `#ec4899` border.
- Motion: 150ms price fade on toggle; none under reduced motion.

### Components & interactions
SiteHeader, SegmentedControl, PlanCard, SubscribeButton (spinner, redirects; when subscribed becomes "Manage"), LogoCaptionRow, SiteFooter, AccountCard (body + footer with hint text and action), Toast. Signed-out Subscribe routes to /signin?next=/.

### Data & state
Tables: `products`, `prices`, `customers(id, provider_customer_id)`, `subscriptions(user_id, status, price_id, quantity, cancel_at_period_end, current_period_end)`, `users(id, full_name, avatar_url)`. Webhooks upsert products/prices on change and subscriptions on lifecycle events. Seed four invented plans with monthly and yearly prices.

### Accessibility
Segmented control is a radiogroup. Featured plan says "Recommended" in text. Subscribe buttons have names like "Subscribe to Freelance plan". Caption stays under five words. Focus ring 2px `#ffffff` with 2px offset.
Verified contrast: body text: #ffffff on #000000 = 21.0:1; subtitle: #e4e4e7 on #000000 = 16.55:1; muted on card: #a1a1aa on #18181b = 6.91:1; subscribe label: #27272a on #ffffff = 14.89:1; segmented label: #ffffff on #3f3f46 = 10.44:1; featured outline: #ec4899 on #000000 = 5.95:1; input border: #71717a on #18181b = 3.67:1; focus ring: #ffffff on #000000 = 21.0:1.

### Security
- RLS: `products`, `prices` public select; `customers` no client access; `subscriptions` select where `user_id = auth.uid()`; `users` select/update own row only.
- Webhook verifies signatures, uses the service role key server-side only, and is idempotent.
- Checkout sessions are created server-side from a validated active price id; rate-limit per user.
- Email change requires confirmation; validate names with zod (1-64 chars).

### Performance & SEO
Pricing page is statically generated and revalidated on product webhook. Minimal JS: only the toggle and buttons hydrate. Title, description, OG image; noindex /account.

### Guardrails
- Invent plan names, copy and prices; use placeholder marks instead of real logos.
- Never show subscribe for a plan the user already has.
- Acceptance criteria: (1) plan edits at the provider appear after a webhook; (2) monthly/yearly switch is correct for every plan; (3) test checkout creates an active subscription; (4) account updates persist and validate; (5) pure-black page passes all contrast checks.

Open the builderAll templatesThis palette on its own