Architecture
The ui-kit is the visible layer of a stack. Beneath it, core-server holds the backend modules and domain holds the pure business rules. The three ship together, so a product always runs a matching set.
What customers use
@hch-shared-libraries/ui-kit
400+ Angular components, from the app shell and data tables to the accounting screens and the video studio. One design system, themed per tenant.
@hch-shared-libraries/core-server
100+ backend modules: identity, audit, messaging, payments, storage, scheduling and the ledger. Written once, hardened once, reused by every product.
@hch-shared-libraries/domain
The business rules as pure code with no framework: money, access, tax, scheduling, the accounting ledger. The browser and the server run the same function, so a rule can never drift between them.
AI-led development
AI can write an application quickly. On the ui-kit it does not have to reinvent the business functions every application needs, so it gets to a finished product faster and with fewer surprises.
An AI assistant that starts from a blank page rebuilds logins, invoicing and audit trails from scratch every time. On the ui-kit it composes business functions that already exist, so its effort goes into what makes your product different.
Every component and module is written once, tested once and reviewed once. AI-built products inherit that assurance instead of each carrying its own unreviewed copy of the same feature.
Left alone, AI writes a slightly different version of the same code in every product. Shared parts remove that duplication, so a fix or an improvement reaches every product on the next release.
Every export is documented for an AI reader, with what it needs, what it emits and the questions to ask the developer. Conventions are enforced by lint and tests, so a wrong turn fails the build instead of reaching production.
Data classification, audit logging, field-level encryption, access control and retention are native to the platform, which maps to the controls behind ISO 27001, SOC 2 Type II and HIPAA, so a new product starts with them rather than adding them later.
Because the common business functions are already done, a proof of concept is real, running software on real modules, and the time saved goes to the parts only you can describe.
We are HIPAA self-certified. We do not hold ISO 27001 or SOC 2 Type II certification: the platform is built to support their controls, and your own certification still has to be earned for your product.
The component catalog
From the frame of the app to the last empty state. These are real exports of the library; the lists show a sample of each group.
The frame of an app: header, sidebar, page container and the tenant and role switchers, assembled by one component.
Sign-in, multi-factor and step-up authentication, role switching and audited reveal of sensitive fields.
Tables, lists, boards and charts that stay readable from a phone to a wide monitor.
Schema-driven forms, rich input and one shared filter model from search box to saved views.
Galleries, a multi-angle video studio with annotation, and uploads that resume after a dropped connection.
Interactive maps with drawing tools, typed markers, address lookup and live weather conditions.
Social walls, moderation, translation, AI-assisted writing and a block-based page builder.
A full double-entry accounting surface: ledger, invoices, payments, subscriptions, collections and reports.
Public booking flows, calendars and resource grids over an availability engine shared with the server.
Task lists, templates and a fan-out scheduler that turns one rule into the right tasks for the right people.
Carts, product cards, variant matrices, usage limits and tenant plan billing for selling and subscribing.
Branded templates, previews, a message history across channels, and legal documents with acceptance tracking.
Empty states, skeleton loaders, sync banners and confirmation dialogs, so every screen handles every state.
Every component has a live page with controls to try each option.Browse the component demo
Power
Some of what the kit does is too big to be a component. These are full capabilities a product switches on.
Any product can have real books behind it. The ledger, the invoicing, the collections and the reports are screens and services you mount, not features you build.
A booking flow for the public, a calendar for the staff and one availability engine underneath, shared by the browser and the server.
Capture to playback: resumable uploads, transcoding and streaming on the server, and a studio in the browser for reviewing and annotating footage.
One governed way to send anything: branded templates in, an auditable message out, on whichever channel the person prefers.
Flexibility
A shared library only works if each product can still be itself. The kit is built to be configured, not forked.
Material 3 design tokens drive every colour. Light and dark follow the visitor, and a tenant can bring its own accent colour and logo that the whole interface picks up.
Components take mode inputs and opt-in flags rather than forks. One login page serves sign-in and sign-up; a shell shows only the chrome an app asks for.
Screens talk to a port, an interface the app implements. REST and in-memory implementations ship with the kit, so a demo runs without a backend and a product runs against its own.
Typed extension slots let a product add its own panel to a shared screen, each one behind an error boundary so a broken extension never takes the page down.
Dictionaries load on demand, with English, Spanish, French and German included. Money, dates and units follow the tenant’s region settings.
Every input has a real, associated label, focus is visible and managed, motion respects the visitor’s preference, and the kit is built to WCAG 2.1 AA.
In code
Integration is a template, not a project. These samples come straight from the ui-kit documentation.
<hch-app-shell
app_name="Pitch Spotlight"
[sidebar_items]="nav_items()"
[sidebar_user_permissions]="my_permissions()"
[show_tenant_switcher]="is_multi_tenant()"
[show_role_switcher]="can_view_as_role()"
(login_clicked)="on_login()"
(logout_clicked)="on_logout()"
(tenant_selected)="on_switch_tenant($event)"
(role_selected)="on_switch_role($event)"
></hch-app-shell><mat-card>
<hch-card-header
icon="group"
title="Roster"
subtitle="12 players"
[actions]="[{ icon: 'edit', label: 'Edit', on_click: on_edit_roster }]"
></hch-card-header>
<mat-card-content>...</mat-card-content>
</mat-card>The other half
The screens are backed by core-server: modules for identity, audit, payments, media, messaging and the integrations a business actually uses. Each is a library the app composes, with its persistence supplied by the app.
Secure by default
Security and privacy are conventions of the platform, enforced in code and in review, so a new product starts with them instead of adding them later.
Every row belongs to a tenant, and access is checked against it on the server. One product serves many organisations without their data ever mixing.
Sensitive changes write an append-only audit row in the same database transaction as the change itself, with personal data redacted from the before and after snapshots.
Every field is classified. Health and sensitive personal data are encrypted at the field level, and reading them is logged.
Risky actions ask the person to prove themselves again. Revealing a protected value takes an admin, a re-check and leaves an audit entry.
People are erased by destroying their encryption keys, so the data is unreadable everywhere at once, while financial records are kept intact.
Under-13 users have verifiable parental consent, minimal data and no behavioural targeting, with parent-initiated deletion built in.