Sumlight

A mock-up of the screen, drawn from its layout, palette and typefaces. A build follows the full prompt below.

Start from this screenRead the build prompt

Typefaces

The catalog's own faces. A screen composed into a template is drawn in that template's typefaces.

• InterHeadings: Inter 500, 32px centered H1; 28px credits figure (600, tabular)
• InterBody: Inter 400 16px; 14px labels; 13px chips in JetBrains Mono

Patterns

• centered settings header with segmented tabs (Personal / Organization / Billing)
• plan card with icon, name, price and Upgrade button
• monospace limit chips
• large remaining-credits figure with progress bar
• refresh-date helper with info tooltip
• sidebar upgrade nudge card
• credits counter in top bar
• floating Support pill

States it is designed for

• Free plan (this screen)
• Paid plan (manage subscription, invoices list)
• Low credits (<10%: amber bar and banner)
• Out of credits (requests paused banner, red)
• Payment failed / past due
• Loading skeleton
• Non-admin (read-only, Upgrade disabled with tooltip)

Who it is for

• Developers using a metered API
• Startup founders watching usage costs
• Team admins managing an organisation plan

Layout

1. Top bar: workspace switcher and search left; credits counter right
2. Left sidebar: Overview; PRODUCTS (Data APIs, Monitors, Batches, Logo link); WORKSPACE (API keys, Usage, Team); upgrade nudge card; Help, Documentation, org row
3. Main (max ~490-640px, centered): H1 "Settings", subline, segmented tabs, plan card containing an inner grey panel with limit chips, credits figure and bar, helper line
4. Support pill fixed bottom-right
5. Mobile: sidebar in drawer; plan card full width; Upgrade button below plan name

Palette

clean, transparent, developer-friendly, calm. Billing that reads like a status report rather than an advert.

• page background#f7f7f7
• plan card#ffffff
• inner usage panel#f4f4f4
• primary text#111111
• helper and labels#5c5c66
• Upgrade buttons, progress fill#1e6ff5
• button label#ffffff
• limit chip outline#8a8a8a
• progress track#d4d4d8
• low-credit state#b45309

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

Inter 500, 32px centered H1; 28px credits figure (600, tabular)

Body

Inter 400 16px; 14px labels; 13px chips in JetBrains Mono

Similar to the observed grotesk with a mono accent for quotas; sidebar group labels 12px uppercase in outlined tags with 0.06em tracking.

Spacing and imagery

Airy: 8px base; card padding 16px, inner panel 16px; radius 12px card, 8px panel, 6px chips and buttons; card shadow 0 1px 2px rgba(0,0,0,.04).

Small sparkle/constellation plan icon; outline sidebar icons; no photos.

Components

• Workspace switcher
• Credits counter
• Grouped sidebar with outlined group tags
• Segmented tabs
• Plan card
• Limit chips
• Credits meter (figure, denominator, bar)
• Info tooltip
• Upgrade nudge card
• Support pill
• Plan comparison dialog

Interactions

• Upgrade opens a plan comparison dialog; choosing a plan redirects to a hosted checkout provider
• Tabs are URL-routed
• Info icon tooltip explains what happens at zero credits
• Credits counter updates live after API calls (poll or realtime)
• Progress bar animates on load

Data

• Organization{id, name}
• Plan{id, name, price_month, credits_month, rate_limit_per_min}
• Subscription{org_id, plan_id, status (active|past_due|canceled), renews_at}
• CreditBalance{org_id, remaining, period_start, refreshes_at}
• Invoice{id, org_id, amount, status, pdf_url}

Guardrails

Experience

• Say plainly what happens at zero credits and when they refresh
• Show remaining as a number and a bar, with the denominator
• Upgrade is visible but not repeated more than twice per screen
• Use the org's locale for dates and currency
• Link to usage details from the meter

Accessibility

• Meter uses role="meter" (or progressbar) with aria-valuenow/max and text
• Warn states use icon + text, not colour alone
• Tooltip content also reachable on focus
• Tabs follow tablist pattern with arrow keys
• Mono chips have readable 13px size

Security

• Only org admins can change plans (RLS + server check)
• Checkout sessions created server-side; no card data touches the app
• Balance computed from server usage records; client cannot edit
• Webhook signatures verified before updating subscription

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 **Sumlight**, the Billing tab of a developer data-API product. A centred page shows the plan (Free, $0/month), its limits as monospace chips (1,000 credits/mo, 30 requests/min), a big "Remaining credits" figure with a bar, and a line saying when credits refresh and that requests stop at zero. Upgrade leads to a plan comparison and a hosted checkout.

### Stack
Next.js (App Router) + TypeScript, Tailwind CSS, shadcn/ui (Tabs, Dialog, Tooltip, Progress, Skeleton) on Radix, lucide-react, TanStack Query, date-fns. Supabase for auth, orgs, subscriptions and usage; server routes create sessions with a hosted checkout provider and receive its webhooks.

### Pages & layout
1. **Top bar**: workspace switcher and search icon on the left; a credits counter with a small icon on the right.
2. **Sidebar**: Overview; a PRODUCTS tag with Data APIs, Monitors, Batches, Logo links; a WORKSPACE tag with API keys, Usage, Team; an upgrade nudge card ("You're on the free plan" + Upgrade); Help, Documentation, and the org row.
3. **Main** (640px centred): H1 "Settings", subline "Manage organisation details, subscription and billing", segmented tabs (Personal, Organization, Billing).
4. **Plan card**: plan icon, name and price, Upgrade button right; inner grey panel with limit chips, a divider, "Remaining credits" label, a large figure "742 / 1,000" and a progress bar, and a helper line with an info tooltip ("Refreshes Nov 3 with 1K credits").
5. Below on paid plans: payment method and an invoices table.
6. A Support pill fixed bottom-right. Mobile: drawer sidebar, stacked card.

### Design system
- Colors: `--canvas: #f7f7f7` (page background), `--card: #ffffff` (plan card), `--panel: #f4f4f4` (inner usage panel), `--fg: #111111` (primary text), `--muted: #5c5c66` (helper and labels), `--primary: #1e6ff5` (Upgrade buttons, progress fill), `--on-primary: #ffffff` (button label), `--chip-border: #8a8a8a` (limit chip outline), `--track: #d4d4d8` (progress track), `--warn: #b45309` (low-credit state).
- Fonts: Inter (similar to the observed grotesk): H1 32px/500, credits figure 28px/600 with tabular numerals, body 16px/1.5, labels 14px; JetBrains Mono 13px for chips; sidebar tags 12px uppercase with 0.06em tracking.
- Spacing: 8px scale; 16px card and panel padding; 24px section gaps.
- Radius: card 12px; panel 8px; chips and buttons 6px; Support pill full.
- Shadows: card `0 1px 2px rgba(0,0,0,.04)`.
- Motion: bar fills over 500ms on load; none under reduced motion.

### Components & interactions
TopBar with CreditsCounter (refreshes via polling or a realtime channel), Sidebar with UpgradeNudge, SettingsTabs (URL-routed), PlanCard, LimitChips, CreditsMeter (normal, low in amber, empty in red), InfoTooltip (hover and focus), PlanCompareDialog (three invented tiers with a monthly/yearly toggle), InvoicesTable, SupportPill, Banner.

### Data & state
Tables: `plans`, `subscriptions(org_id, plan_id, status, renews_at)`, `credit_balances(org_id, remaining, period_start, refreshes_at)`, `invoices(id, org_id, amount, status, pdf_path)`. Mock the free plan with 742 of 1,000 credits remaining. Handle states: free, paid, low credits, out of credits, past due, loading, non-admin read-only.

### Accessibility
The meter has role and values plus visible text. Warning and error banners use an icon and text. Tooltips open on focus. Tabs support arrow keys. The Upgrade button is disabled for non-admins, with a tooltip saying why. Focus ring: 2px blue with offset.
Verified contrast: body on card: #111111 on #ffffff = 18.88:1; muted helper on panel: #5c5c66 on #f4f4f4 = 6.01:1; button label on blue: #ffffff on #1e6ff5 = 4.52:1; text on canvas: #111111 on #f7f7f7 = 17.63:1; chip border on panel: #8a8a8a on #ffffff = 3.45:1; progress fill on panel: #1e6ff5 on #f4f4f4 = 4.11:1; low-credit warning text: #b45309 on #ffffff = 5.02:1.

### Security
RLS: org members read billing; only admins create checkout sessions, and the server checks the role. The server creates checkout sessions and verifies webhook signatures before updating `subscriptions`. Balances derive from server usage logs; the client cannot write them. Invoice PDFs are served through signed URLs.

### Performance & SEO
Server-render the tab with current balance; hydrate the counter. Cache plan metadata. Settings routes are noindex.

### Guardrails
- Invented product name, plans and prices.
- Never hide what happens at zero credits.
- Acceptance criteria: (1) the meter shows number, denominator, bar and refresh date; (2) low and empty states change colour and add text; (3) Upgrade flows through server-created checkout; (4) non-admins cannot upgrade; (5) contrast and keyboard checks pass.

Open the builderAll templatesThis palette on its own