Design System
HTML Markdown

Page Patterns

Payd Labs products reuse a small set of page types. Keep these patterns stable across projects so users can move between tools without relearning structure.

Admin Dashboard

Use for Stables, OneLink, Secret Share, Sentinel, Knowhere, and similar tools.

Structure:

  1. Fixed header and sidebar.
  2. Compact page title.
  3. Metric cards or action row.
  4. Status breakdown, operational table, or recent activity.

Rules:

  • Do not add a marketing hero to dashboard home pages.
  • Keep metrics in a 2-by-4 responsive grid.
  • Put filters above tables, not in separate decorative cards.
  • Prefer exact record state over generic copy.

Login And OTP

Structure:

  1. Centered logo and product name.
  2. Optional one-line product purpose.
  3. Error alert if needed.
  4. Surface card with form.
  5. OTP step in the same card.

Rules:

  • Card max width is usually max-w-sm.
  • Logo height is 28-32px.
  • Product title is 18px.
  • Form labels are 12px.
  • Primary action is full width and accent green.
  • OTP values use mono or fixed numeric boxes.

Checkout Or Payment

Use for customer-facing payment flows.

Structure:

  1. Header with Payd logo and theme control.
  2. Centered or constrained payment panel.
  3. Amount, network, asset, address, timer, and action.
  4. Success, expired, failed, and underpaid states.

Rules:

  • Use the same tokens but allow more whitespace.
  • Amounts and addresses should not shift during polling.
  • QR containers can use larger radius, but still need border and surface logic.
  • Keep copy direct and action-oriented.

Docs Site

Use for API and design references.

Structure:

  1. Header or docs shell with logo and theme toggle.
  2. Sidebar or local nav.
  3. Prose content with code samples, tables, and callouts.

Rules:

  • Prose h1 can be 32px.
  • Prose h2 is around 22px with bottom border.
  • Code blocks use JetBrains Mono, 13px, 1.7 line height.
  • Tables use the same border and header treatment as app tables.

Control Plane

Use for Sentinel and Knowhere-style infrastructure tools.

Structure:

  1. Same admin shell.
  2. Summary cards for system status.
  3. Tables for deployments, domains, projects, previews, and audit events.
  4. Explicit action rows for deploy, promote, rollback, restart, verify.

Rules:

  • Keep irreversible or infrastructure-changing actions approval-gated.
  • Use warning and error states for operational risk.
  • Keep system output readable in monospace or dense tables.
  • Avoid user-facing internal readiness labels. Show actual status and next available action.

Detail Page

Structure:

  1. Back or breadcrumb action.
  2. Title, status pill, primary metadata.
  3. Cards for grouped facts.
  4. Table or event list for history.
  5. Action panel where needed.

Rules:

  • Use mono for record IDs, hashes, addresses, and API paths.
  • Use secondary text for labels.
  • Put destructive actions away from routine actions.

Empty States

Empty states are compact:

  • Icon if useful.
  • One sentence that names the empty data.
  • One clear action if available.

Do not use empty states to explain internal project readiness.