Overview
Composable UI primitives built for real SaaS interfaces. Designed to scale from product validation to production.
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.
| Need | Use |
|---|---|
| Button action | UI component |
| Form input | UI component |
| Form validation flow | Guide |
| Data table with loading, empty, error, filters | Pattern |
| Dropdown vs Dialog vs Sheet decision | Pattern |
| Mutation feedback with toast, retry, undo | Pattern |
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.