What this is ready for, and what it isn't.
Two questions hide inside "is it enterprise-grade", and they have opposite answers. The architecture is largely production-quality. The system is roughly a fifth of one. This page separates them, quantifies the gap, and says what it would cost to close.
The verdict
Is the architecture enterprise-grade?
Largely yes. The three-layer token model with a one-way dependency rule is how Carbon, Spectrum and Polaris are built, and most systems that fail do so because products reach past the semantic layer — this one lints against that. Density tiers, measured contrast, a motion ceiling, a deprecation lifecycle and decision records are all present and are the parts teams usually retrofit badly.
Is the system ready to deploy?
No. Thirteen components against the fifty-plus a real enterprise application needs. No data grid, date picker, combobox or menu. No React package, no TypeScript, no Storybook, no Figma library. No RTL. No third-party accessibility audit. Those are not hard problems — they are long ones, and they are most of the calendar time.
What is ready
Not a courtesy list. These are the parts that are genuinely hard to get right and are done.
| Capability | State | Why it matters at scale |
|---|---|---|
| Three-layer token model | Ready | The one-way dependency rule is the difference between a design system and a stylesheet. Enforceable by lint, and the reason a theme or pitch change does not require touching products. |
| Density tiers | Ready | Compact / default / comfortable from a single attribute. Enterprise consoles need this and it is painful to retrofit — Carbon and Spectrum both have it, most in-house systems do not. |
| Dual theme | Ready | Both complete, neither an afterthought. Every semantic role defined in both. |
| Measured contrast | Ready | Published figures computed from the palette, not asserted, with the intention of CI verification. Most systems publish intentions. |
| Accessibility floors | Ready | 44px targets enforced inside the token via max(), including at compact density. Focus policy, reduced-motion policy, non-text contrast on control boundaries. |
| Motion specification | Ready | Duration ceiling measured end-to-end across sequences, an animatable-property allow-list, reduced motion as removal rather than shortening. |
| Governance model | Ready | Deprecation lifecycle, removal ledger, decision records, derivation-proof review rule, annual breaking release. More disciplined than many funded systems. |
| Email and print | Ready | Token resolution at build time for surfaces without var(), and a print stylesheet with the lattice re-seeded in millimetres. Genuinely rare — most enterprise systems have no answer for Outlook at all. |
| Documentation | Ready | Thirteen sections including the system's own failures. An evaluator can determine fitness without a call, which shortens procurement. |
Gap analysis
Blocker — cannot ship without. Major — needed by most enterprise applications. Minor — needed eventually. Effort assumes one designer and two engineers.
Components — 46 of 58
| Missing | Severity | Note | Effort |
|---|---|---|---|
| Data grid — virtualised, sortable, filterable, resizable, frozen columns, bulk select, column chooser | Part-built | The single largest item. Every fintech and most healthcare applications are a data grid with a shell around it. Now built for read-heavy use — virtualised, sorted, filtered, resizable, freezable, selectable, with full ARIA grid semantics. Cell editing, grouping, column virtualisation and server-side data remain absent. | Read-heavy: done. Editing and grouping: adopt headless, 4–6 wks |
| Menu / dropdown, tooltip, popover | Part-built | Shipped with focus management and dismissal, but naive viewport-flip placement — no scrolling-container or transformed-ancestor handling. Swapping in Floating UI is a contained change. | 1 wk to swap placement |
| Combobox / autocomplete, multiselect | Blocker | The hardest ARIA pattern in common use. Do not hand-roll. | 3–4 wks on a headless base |
| Date picker, range picker, time picker | Blocker | Locale, calendar systems, keyboard grid, screen-reader announcement of a two-dimensional widget. | 4–6 wks on a headless base |
| Drawer, accordion, breadcrumb, pagination, tag, avatar, skeleton, spinner, banner, split button, search, number input, slider, file upload | Shipped | All present in the library, tokens-only, both themes, forced-colors path. | Done |
| Tree view, command palette, notification centre, wizard, filter panel, bulk action bar | Major | Application patterns rather than primitives. Toolbar now shipped. | 5–7 wks |
| Charts | Major | The showcase draws SVG charts by hand. A real system needs a themed charting layer with accessible data tables behind every visualisation. | 4–6 wks on a charting base |
| Icon system | Major | Sizing is specified; there are no icons. Adopt a set rather than draw 300. | 2 wks to integrate |
Engineering
| Missing | Severity | Note | Effort |
|---|---|---|---|
| Framework package — React first, TypeScript types | Blocker | Raw CSS is adoptable by nobody's component team as-is. Angular matters in banking specifically. | 6–8 wks |
| npm publishing, semver releases, changelog automation | Blocker | Governance describes a release model that has no release mechanism behind it. | 2 wks |
| Storybook | Major | The documentation site is excellent for evaluation and useless as a component workbench. | 2–3 wks |
Style Dictionary build from tokens.json | Major | The JSON exists and nothing consumes it. Emit CSS, JS, Swift, Kotlin, Figma. | 2 wks |
| SSR and tree-shaking | Major | Assumed by every modern enterprise front end. | Folded into the package work |
| Browser floor decision | Major | CSS custom properties are load-bearing everywhere. If a client still requires IE11 — some banks do — this system cannot be used at all without a compiled fallback build. | Decision, then 3–4 wks if needed |
| Performance budget | Minor | No bundle-size ceiling, no render benchmarks. | 1 wk |
Accessibility and compliance
| Missing | Severity | Note | Effort |
|---|---|---|---|
| Third-party audit and VPAT / ACR | Blocker | Procurement asks for the document, not the intention. Required for US federal (Section 508), most healthcare, and increasingly EU under the European Accessibility Act. | 4–8 wks plus external cost |
| Forced-colors / Windows High Contrast | Blocker | Unsupported by the base system — state carried by fills disappears entirely. Now addressed in the enterprise subset. | Done |
| High-contrast theme | Major | AAA palette for users who need it and for procurement checklists. Now addressed in the subset, measured at ≥ 8:1. | Done |
| Screen-reader test matrix | Blocker | Claims are made; results are not published. NVDA/JAWS/VoiceOver × browser, per component. | 3–4 wks |
| WCAG 2.2 review | Major | The system targets 2.1. 2.2 adds focus-appearance and target-size criteria that mostly favour it, but the delta is unassessed. | 1–2 wks |
| Cognitive accessibility patterns | Minor | Error recovery, plain language, timeout extension — specified nowhere. | 2 wks |
Internationalisation
| Missing | Severity | Note | Effort |
|---|---|---|---|
| RTL | Blocker | Zero support. Not a mechanical flip either — the dot rail, the travelling loop and the curl boundary all encode direction and need deliberate mirroring. Rules must move to logical properties throughout. | 3–6 wks |
| Locale typography | Major | CJK line-height and vertical rhythm are untested; German compound words will break control widths sized in ch; Devanagari and Tamil ascender/descender behaviour untested despite the system's own origins. | 3–4 wks |
| Number, date and currency formatting | Major | No tabular-figure rule, no negative-value convention, no currency alignment guidance. Fintech-critical. | 2 wks |
| Translation expansion | Minor | No 30–40% expansion testing on labels and buttons. | 1 wk |
Design tooling and organisation
| Missing | Severity | Note | Effort |
|---|---|---|---|
| Figma library | Blocker | Designers cannot use this today at all. Variables for the seed, three colour modes, density as a mode, published components. | 4–6 wks |
| Code Connect / design-to-code mapping | Minor | Nice once the Figma library and React package both exist. | 1–2 wks |
| Funded team and SLA | Blocker | Enterprises adopt systems that will still exist in three years. A one-person side project does not clear that bar however good it is — this is an organisational fact, not a quality judgement. | — |
| Adoption metrics and migration tooling | Minor | Codemods are promised in governance and do not exist. | 2–3 wks |
Domain fit
The three verticals are not equally good matches, and healthcare is the one to be careful about.
Fintech — the strongest fit
Works in its favour
- Compact density is genuinely well-suited to ops, reconciliation and trading surfaces, and it is derived rather than hacked.
- Measured contrast discipline matters as consumer banking moves toward hard accessibility conformance in the EU.
- The email and print layer — statements, confirmations, regulatory correspondence. Rare and directly useful.
- Dark theme is native, not an inversion, which suits long-session monitoring work.
Blocks it today
- No data grid. A styled
<table>is not a grid. This alone rules out most applications. - No number system — tabular figures, negative-value conventions by locale, precision and rounding display rules, currency alignment.
- No real-time value pattern — updating figures without layout shift or focus loss.
- No audit-trail, session-timeout or step-up-authentication patterns.
- Disclosure typography — regulated fine print has minimum-size and prominence rules the type scale does not address.
Healthcare — the hardest fit
Specific hazards
- The crossing checkbox. An X reads as remove to many software users. Reverted in the regulated profile.
- Red and green carry established clinical meanings that will collide with generic success and danger semantics.
- The pattern layer near clinical data — the density ceiling is not enough; it should be absent entirely.
- Compact density is questionable with gloves, styluses, shared workstations and users who are standing. The regulated profile refuses to go below default.
- PHI masking and reveal, screen-privacy states, and alert-fatigue hierarchies are entirely unaddressed.
What could still be used
- The token architecture and derivation discipline — domain-neutral.
- The density model, at default and comfortable.
- The accessibility floors and the high-contrast theme.
- The governance model, which is arguably the most transferable artefact here.
- Nothing from the expressive layer, and none of the redesigned controls.
Large service organisations
These hit multi-brand and localisation walls before they hit component gaps. Forking is well-specified — under twenty lines — but there is no white-label tooling, no theme-management story at scale, and no RTL, which rules out any organisation operating in the Gulf, Israel or much of South Asia's Urdu-language market. The strongest single argument for this system in a service organisation is the email and print layer, because large services send an enormous volume of both and almost no design system covers them.
Roadmap
Sequenced by what unlocks the next thing, not by what is most interesting. Durations assume one designer and two engineers; halve the team and roughly triple the calendar.
Choose the target before building anything
- Pick one vertical. Fintech is the strongest fit. Trying to serve all three produces a system that fits none.
- Decide the expressive layer in or out for that vertical, using the cultural test below.
- Decide build versus adopt per hard component. Grid, combobox, date picker and floating elements should almost certainly be headless libraries wearing these tokens.
- Set the browser floor. If IE11 is required, stop — this system's architecture is incompatible and that must be known now.
Unlocks: everything. Getting this wrong wastes the following nine months.
From a website into something a team can install
- Style Dictionary build from
tokens.json→ CSS, JS, Figma. - React package with TypeScript types, SSR-safe, tree-shakeable. npm, semver, automated changelog.
- Storybook for the thirteen existing components.
- Figma library: seed as number variables, three colour modes, density as a mode.
Unlocks: a designer and an engineer can both use it. Until this exists nothing else matters.
Turn good practice into evidence
- RTL throughout — logical properties, and deliberate mirroring of the rail, the loop travel and the curl boundary.
- Screen-reader test matrix published per component.
- WCAG 2.2 delta review.
- Third-party audit → VPAT / ACR.
- CI: contrast recomputation, target-size assertion, duration allow-list, forced-colors smoke test.
Unlocks: procurement conversations. Without a VPAT most regulated buyers cannot proceed regardless of quality.
The twenty-five components that unblock a real application
- Floating layer: menu, tooltip, popover, drawer — on Floating UI.
- Input layer: combobox, multiselect, date and range picker, number, search, file upload, slider.
- Navigation layer: breadcrumb, pagination, tree, toolbar, command palette.
- Feedback layer: skeleton, spinner, banner, notification centre.
- Data grid, skinned onto a headless base rather than built.
Unlocks: a team can build a full product without leaving the system.
The work that never finishes
- Locale typography, number and currency systems, translation expansion.
- Charting layer with accessible data tables behind every visualisation.
- Multi-brand tooling; performance budget; migration codemods.
- Vertical patterns — audit trails, session timeout, PHI masking, bulk operations.
- LTS policy alongside the annual Margazhi break.
Team and cost
Minimum viable team
- Design systems designer1.0 FTE
- Front-end engineers2.0 FTE
- Accessibility specialist0.3 FTE
- Technical writer0.2 FTE
- External auditone-off
Below roughly 2.5 FTE sustained, enterprise design systems tend to stall at the point where maintenance load equals build capacity.
The cheaper path
Do not build a component library. Take the token architecture, the density model, the accessibility floors, the motion spec and the governance model — which is the genuinely valuable and genuinely finished part — and apply them on top of an existing headless or unstyled component library.
That is three months rather than twelve, it inherits somebody else's accessibility testing, and it loses almost nothing that this system is actually good at. The components were never the contribution.
The cultural decision
The question no gap analysis covers, and the one that should be settled first.
Should a global bank or a US hospital network use a kolam-derived visual language at all? This system's own documentation says no: for a product with no relationship to that context it reads as ornament borrowed for novelty. That is a real ceiling on generic enterprise adoption, and it is not solved by doing the borrowing more tastefully.
It is also separable. The measurement layer, the governance model, the motion specification and the accessibility floors are entirely domain-neutral. An enterprise can adopt all of that and never draw a kolam — which is exactly what the enterprise subset is for.
The three-question test
- Does the organisation have a genuine relationship to the context? Indian market, Indian users, Indian heritage. If no, the expressive layer is off.
- Is the surface regulated? If clinical or safety-critical, the expressive layer is off and the controls revert regardless of the answer above.
- Can the organisation credit the source properly? Naming kolam practice and the formal-grammar research in its own documentation, not just inheriting ours. If it will not, it should not use the visual language.
Evaluate it yourself
The checklist an enterprise evaluator should run against this or any other design system. Most of these questions have a public answer here; the ones that do not are marked.
| Question | Answer for Pulli |
|---|---|
| Can a product accidentally reach past the semantic layer? | No — and it is lint-enforceable |
| Are contrast figures measured or asserted? | Measured, published, both themes |
| Do target sizes hold at the densest tier? | Yes — floored inside the token |
| Is there a forced-colors story? | Yes, in the enterprise subset |
| Is there a VPAT? | No |
| Is there a screen-reader test matrix? | No |
| Does RTL work? | No |
| Is there a data grid? | Read-heavy yes, editing no |
| Is the component inventory published? | Yes — 46 of 58, auditable |
| Can designers use it? | No Figma library |
| Can engineers install it? | No package |
| Is deprecation specified and tooled? | Specified, not tooled |
| Will it exist in three years? | Unfunded — the honest answer is unknown |