Solid Design System Pro: the full system for teams managing multiple product surfaces
Solid Pro is the expanded tier of the Solid Design System. Where Solid gives you the foundational components and token structure to build consistently, Solid Pro extends that foundation with deeper component breadth, more opinionated layout primitives, advanced theming capabilities, and documentation patterns that cover the use cases teams actually encounter when managing front end code across more than one surface.
Beyond the basics: what the expanded component set covers
The core Solid system covers the components that every project needs: buttons, forms, cards, alerts, navigation, and typographic primitives. Solid Pro starts there and keeps going. The extended library adds data display components like tables with sortable headers and inline editing states, dashboard card variants with metric formatting, stepper and wizard patterns for multi-step flows, and advanced modal compositions that handle nested content without layout collapse.
Each component ships with documented states. Not just "default" and "hover," but disabled, loading, error, empty, and overflow states. These are the states that break layouts in production because nobody thought about them during the initial build. A dropdown that looks fine with five items and catastrophic with fifty. A card that handles a two-line title but wraps awkwardly with four. Solid Pro documents those edge cases and provides the CSS and structural patterns to handle them.
The component set is not exhaustive for the sake of being exhaustive. Every component in the Pro tier exists because it solves a recurring problem in real product work. There are no decorative-only components and no showcase pieces that look good in a demo but serve no practical purpose in a shipping application.
Theming that works at the token level, not just color swaps
Most theming systems start and end with colors. Swap the primary from blue to green, update a few accent values, and call it themed. That approach falls apart the moment you need to adjust spacing density, change border radius conventions, or modify the typographic scale for a different product context.
Solid Pro structures theming at the design token level. Colors, spacing, typography, border radius, shadow depth, and transition timing are all expressed as tokens. Changing the visual character of the system means adjusting tokens, and those adjustments cascade predictably through every component that references them.
This matters most when a team ships multiple products that need to feel related but not identical. An internal admin tool, a customer-facing dashboard, and a marketing site can share the same component architecture while each having distinct visual identities. The components behave the same, the states work the same, but the surfaces look like they belong to different products. That is what token-level theming enables, and it is fundamentally different from the color-swap approach.
Layout primitives that reduce boilerplate
Every project includes layout code that nobody wants to write but everybody needs. Content containers with max-width constraints and responsive padding. Sidebar-plus-content compositions that collapse to single-column on narrow viewports. Header-body-footer stacking patterns that handle variable content height without footers floating in the middle of the screen.
Solid Pro ships layout primitives that handle these patterns. They are not full page templates in the sense of a pre-built admin dashboard. They are lower-level structural components that teams compose into their own layouts. A stack primitive for vertical rhythm. A cluster primitive for horizontal grouping with consistent gaps. A sidebar composition that handles the responsive breakpoint and content reflow without custom media queries in every project.
These primitives reduce the amount of one-off layout CSS that accumulates in a codebase. They also create consistency across pages and product surfaces because every layout uses the same spacing tokens and breakpoint logic rather than each developer writing their own version with slightly different values.
What the documentation covers and how it is structured
Solid Pro documentation is organized around the way developers actually look things up. Component pages show the component in its default state, list all available props and variants, document each interactive state, and include usage notes that explain when to use the component versus when a different pattern is more appropriate.
Beyond individual components, the documentation covers composition patterns. How to combine a card component with a table inside it. How to nest form groups within a stepper. How to use layout primitives to create a settings page that stays usable as the number of settings grows. These composition examples are where most design system documentation stops being useful, and Solid Pro makes them a first-class section.
The documentation is live and browsable. You can explore the full Solid documentation overview, see components in action at the Solid component demo, and follow the getting started guide to understand the integration path before committing to adoption.
When Solid Pro is the right choice
Solid Pro is built for teams managing more than one product surface. If you ship an internal tool and a customer-facing application that need to share component conventions but have distinct visual identities, the token-level theming makes that feasible without maintaining two separate component libraries.
It is also the right choice for teams that have outgrown a starter kit. You started with a handful of base components and consistent colors, and now you are writing custom layout CSS for every new page, inventing loading states ad hoc, and realizing that your "design system" is actually just a shared CSS file with some variables. Solid Pro gives you the structured upgrade path from that situation without requiring a complete rewrite.
Teams building dashboards, admin interfaces, multi-step workflows, and data-heavy product surfaces will find the most immediate value. These are the contexts where component states matter most, where layout primitives prevent the most boilerplate, and where governance documentation saves the most arguments about how things should work.