UIUpdated April 28, 2026

Overview

Composable UI primitives built for real SaaS interfaces. Designed to scale from product validation to production.

UIComposable primitives

Build interfaces that scale with your productLink to section

PyColors UI components are small, composable primitives built for real SaaS interfaces.

They are designed to help you build:

  • dashboards
  • forms
  • settings pages
  • billing surfaces
  • admin tools
  • auth flows
  • data-heavy product views

This is not a UI kit for isolated demos.

It is a component foundation for products that need to evolve without becoming inconsistent.

Core idea

UI components are the lowest product layer. They should stay small, token-driven, and predictable.

Where UI fitsLink to section

PyColors is organized as a product system, not only a component library.

Design System

Tokens, colors, typography, radius, and shadows define the visual foundation.

UI Components

Small reusable primitives consume the design system and stay easy to compose.

Guides

Guides explain how primitives behave inside real product experiences.

Patterns

Patterns combine components, state, behavior, and UX into reusable product blocks.

Starters

Starter Free and Starter Pro connect primitives into full SaaS product foundations.

Mental modelLink to section

Tokens define the system. Components stay small. Guides explain usage. Patterns handle complexity. Starters connect everything into a product.

This keeps the UI layer focused.

If a primitive starts carrying too much product logic, the abstraction is probably in the wrong place.

Start with the essentialsLink to section

Component categoriesLink to section

Composition rulesLink to section

Start with semantic tokensLink to section

Use token-driven utilities such as bg-card, text-muted-foreground, border-border, and shadow-sm.

Components should consume meaning, not raw visual values.

Compose before configuringLink to section

Prefer composition over large prop APIs.

If a component needs too many product-specific props, extract the product behavior into a pattern.

Keep interaction ownership clearLink to section

A primitive should usually own one interaction responsibility.

Complex flows like forms, tables, overlays, and async actions belong in Guides or Patterns.

Use UI for structure, not business logicLink to section

Components should render state clearly.

Product rules, billing checks, auth ownership, and backend decisions should stay outside the primitive layer.

When to use PatternsLink to section

Use a UI component when you need a primitive.

Use a Pattern when you need a product behavior.

NeedUse
Button actionUI component
Form inputUI component
Form validation flowGuide
Data table with loading, empty, error, filtersPattern
Dropdown vs Dialog vs Sheet decisionPattern
Mutation feedback with toast, retry, undoPattern

Rule of thumb

Components render building blocks. Patterns explain how those blocks behave in a real product.

What to avoidLink to section

Prefer

  • small primitives
  • semantic tokens
  • composition-first APIs
  • clear accessibility defaults
  • patterns for complex flows

Avoid

  • hardcoded one-off styles
  • giant components with too many variants
  • business logic inside primitives
  • using badges as buttons
  • duplicating the same product flow repeatedly

Explore core componentsLink to section

Next stepsLink to section

Build the primitive once. Compose the product many times.

PyColors UI is designed to keep your components simple while your SaaS grows in complexity.