Product Vision
Summary
Build a commercial design-system platform that allows a customer to install a coherent, production-grade product design foundation into a web application and immediately gain access to:
- framework-agnostic UI components built with web standards,
- reusable tokens and foundations,
- opinionated UX and product-design guidance,
- agent-readable documentation that ships with the installed system,
- hosted reference documentation and component examples,
- and ongoing governed releases.
The long-term product is not merely a component library. It is a durable way to package product-design judgment, implementation conventions, and reusable UI primitives so humans and agents can make better product decisions faster.
Problem
Modern product development repeatedly re-solves the same foundational questions:
- Which component or interaction pattern fits this situation?
- How should feedback, destructive actions, overlays, forms, navigation, and data-heavy workflows behave?
- How should typography, spacing, sizing, density, iconography, and component composition relate?
- How can a new project gain a coherent visual and interaction language without rebuilding a design system from scratch?
- How can coding agents make product decisions without relying on generic web conventions or ad hoc research every time?
Existing component libraries often solve only the implementation layer. Many are framework-specific. Many intentionally avoid prescribing product behavior. Strong enterprise systems may include excellent guidance, but are usually tied to a particular organization, design language, ecosystem, or framework.
This product addresses the combined problem: portable implementation plus reusable product judgment.
Primary audiences
Independent builders and small teams
Developers, product managers, founders, and AI-assisted builders who can create software but do not want to design every interaction from first principles.
They benefit from:
- strong defaults,
- immediate visual quality,
- product-pattern guidance,
- low setup cost,
- and agent-readable instructions.
Experienced product builders
Designers and developers who already know how to build good products but do not want to repeatedly recreate their preferred design-system foundation.
They benefit from:
- a coherent starting point,
- configurable visual character,
- stable conventions,
- reusable product patterns,
- and a system that can be extended without being rewritten.
Larger product organizations
Teams that need enterprise-grade consistency, governance, versioning, documentation, and extensibility without being forced into a framework-specific implementation.
Enterprise use is a capability target, not a reason to overcomplicate the initial account or administration model.
Differentiators
1. Web standards first
The canonical web implementation uses standard Web Components rather than separate React, Vue, Angular, or other framework-specific libraries.
The consuming application should not need to choose its framework before it can adopt the design system.
2. Product judgment is first-class
The system documents not only how to use a component, but when and why to choose a pattern.
Examples include:
- modal vs. side sheet,
- toast vs. banner vs. inline alert,
- destructive action patterns,
- selection patterns,
- form structure,
- feedback and validation,
- common product workflows.
Guidance is opinionated, but should distinguish strong recommendations from hard requirements.
3. Agent ready by default
Agent guidance ships with the installed product and is versioned with it.
Agents should be able to discover:
- available components,
- component contracts,
- usage guidance,
- design-system principles,
- product patterns,
- writing guidance,
- and local implementation rules.
An MCP interface may later expose the same knowledge, but the durable source of truth is the versioned documentation and contracts themselves.
4. Coherent customization, not a blank framework
The product has a recognizable default design language, but consuming applications can adjust high-level characteristics such as:
- color,
- typography,
- shape,
- design scale,
- density,
- icon provider,
- and other theme-level decisions.
Customization should preserve system relationships instead of forcing customers to restyle every component independently.
5. Governance is part of the product
Versioning, release notes, deprecation practices, structured component contracts, documentation, and package distribution are not afterthoughts.
The commercial platform should exist early so design-system development happens inside the same release and governance machinery customers will eventually use.
Commercial concept
The current working model is a paid subscription that grants access to the current packages and future releases while the subscription remains active.
If a customer cancels:
- software already installed under a valid entitlement remains usable according to the license,
- access to future protected releases ends,
- and nothing in an existing application should intentionally break because the subscription ended.
Exact license language, registry enforcement, seat rules, and pricing remain separate commercial/legal implementation decisions.
Long-term product shape
The mature product may include:
- web component packages,
- token/foundation packages,
- hosted documentation and Storybook-like component references,
- agent knowledge bundles,
- optional Figma libraries,
- organization and seat management,
- additional implementation targets such as native UI libraries,
- and machine-readable interfaces such as MCP.
The vision does not require all of these to exist at launch.