The design system behind everything we ship.
PDS is Protocore's own design language, extracted from the products we build and hardened in production. Dark-first, token-driven, and documented end to end — the same components that render this site and our client dashboards, packaged so a team can adopt them in an afternoon.
101 production components
From primitives to full page compositions — 101 components, each extracted from a product we ship rather than designed in isolation. If a component is in PDS, it has already done real work: this site, the product demos, and our client dashboards all render on it.
Design tokens
Color, type, space, and motion resolve from one token layer. Change a token and every component follows — no per-component overrides, no drift between products.
Two themes, five accents
A dark and a light theme, five accent colors, all driven by the same tokens. Brand variation is a token swap, not a fork — every product in the family renders from the same system.
Dark-first
Contrast, elevation, and color are worked out on the dark theme first; the light theme derives from the same tokens. The result is a dark mode that feels native, not inverted.
Form primitives
Buttons, inputs, selects, switches, sliders, and field scaffolding — labels, hints, and errors included. The states are already designed: focus, disabled, invalid, and loading behave the same in every product.
Layout and composition
Stacks, grids, dividers, and page shells compose screens without ad-hoc CSS. The largest components are full page compositions — hero, section, and footer patterns lifted from pages we ship.
Navigation
Headers, tabs, breadcrumbs, and menus with their responsive and keyboard behavior built in. The navigation on this site is the component, not an imitation of it.
Overlays
Modals, sheets, drawers, popovers, and tooltips on one layering model — focus trapping, dismissal, and stacking handled once, centrally. No product ships its own z-index arithmetic.
Data display
Tables, lists, stat tiles, badges, and timelines for products that live on numbers. The operator consoles across the family render their density from these components.
Feedback and status
Toasts, banners, empty states, progress, and skeletons — the unglamorous states designed up front. A product built on PDS has a considered answer for loading, empty, and failed.
Typography
An editorial type scale with mono labels for the technical register — the voice you see across every Protocore surface. The scale is tokens, so products tune it without leaving the system.
Motion
Durations and easings ship as tokens with the components already using them. Interfaces move consistently across products because nobody re-times an animation by hand.
Accessible by default
Contrast, focus states, and keyboard behavior are built into the components, not left as an exercise. Ship the defaults and accessibility comes with them.
Zero-runtime CSS
Styling is static CSS resolved at build time — no CSS-in-JS runtime, nothing computed in the browser. The styling layer adds zero JavaScript to the page.
Framework-agnostic CSS layer
The system also ships as a plain CSS package — tokens and utility classes with no React required. Server-rendered pages, emails, and non-React stacks draw from the same source of truth.
Token exports per stack
Tokens export for the web as CSS variables, as a Tailwind preset, and in native formats for mobile platforms. One definition of the brand, consumed wherever the product runs.
Theme provider and hooks
The React layer wraps apps in a provider and exposes tokens through hooks — components read the active theme and accent instead of hardcoding values. Switching themes is state, not a rebuild.
Whitelabel theming
The same mechanism that gives PDS five accents gives a whitelabel product its brand: swap the token values, keep the components. Every whitelabel app in the family is evidence it works.
llms.txt map
A machine-readable map of the whole system — components, tokens, patterns — published as llms.txt. Point an LLM at it and generated code uses real PDS components instead of inventing plausible ones.
MCP server
An MCP server exposes the system to coding agents directly: components, props, and tokens, queryable while the agent builds. The design system answers questions instead of being pasted into prompts.
Documented end to end
Every component lives at pds.protocore.io with live examples, props, and copy-paste code. The docs render on PDS itself — what you read is what you ship.
Versioned releases
PDS ships as versioned packages with semantic versions and changelogs. Upgrades are deliberate: a team moves when it chooses, and the changelog says exactly what moved.
Private registry
Packages install from Protocore's private npm registry with a per-team token in .npmrc — the standard npm workflow, scoped to licensed teams. No vendored zip files, no copy-paste installs.
Offline license keys
A signed license key verifies locally — no phone-home, no network check in your build. Licensing issues surface as development-time warnings and never break a production app.
Licensed per team
PDS is proprietary and licensed per team. Request access and we set you up — packages, docs, and token sources — so a team can adopt it in an afternoon.
The design system, answered.
Per team — not per seat or per project. One licence covers everyone building with PDS inside a team: tokens, components, and the docs. Cost scales with the number of teams that adopt it, nothing else, and whitelabel products we build for you already render on it.
From the private registry at npm.protocore.io. Access credentials let your build pull the @protocore packages; from there the tokens and components install like any dependency.
The tokens are emitted for web, .NET, and native, so one color or radius means the same thing on every platform you ship. Components ship for React, and a framework-agnostic CSS layer carries the same tokens and classes for teams that are not on React.
Dark-first and accessible by default — two themes, five accents, all driven by tokens, with zero-runtime CSS so the styling costs nothing at load. The same components render this site and our client dashboards.
It is built for that: an llms.txt map and an MCP server let agents read the system and build with it correctly, and pds.protocore.io carries live examples, props, and copy-paste code for every component and token.
How PDS is licensed.
Per-team license
PDS is licensed per team, not per seat or per project — one license covers everyone building with it inside that team: tokens, components, and the docs.
Scales with your org
Start with one team and extend across more as adoption grows. What drives cost is the number of teams building on PDS, nothing else.
Inside a Protocore build
Whitelabel products we build for you already render on PDS — the standalone license is for teams adopting it on their own products.
Licensing follows teams, not headcount or usage. Request access and we'll scope it to the teams that will build with it.
Build a screen with PDS.
Live documentation
Browse the full system at pds.protocore.io — live examples, props, and copy-paste code for every component and token.
Token packages
The design tokens emitted for web, .NET, and native, so one color or radius means the same thing across every platform you ship.
Per-team licence
PDS is licensed per team — one licence covers everyone building with it, tokens, components, and docs alike.
Registry access
Credentials for the private registry at npm.protocore.io to install the @protocore packages your build pulls from.
PDS is proprietary and licensed per team. Request access and we'll set you up.
Pick a product. Or take the core.
Everything above runs in production demos we can walk you through — standalone, whitelabel, or as one platform. Tell us what you're building and we'll show you the shortest path to it.
Contact us