Helix
An enterprise cloud operations platform — sixteen product areas, five multi-step forms and a permission model that governs what renders, built on three runtime dependencies.
The problem
- Product areas
- 16
- Runtime dependencies
- 3
- Permission scopes
- 9
Enterprise software is rarely hard one screen at a time. It is hard sixteen screens at a time.
Any one of these areas is tractable on its own. Spend lands on a dashboard, an anomaly becomes an investigation, the investigation leads to a resource, the resource is reconfigured under policy, and every step of it has to appear in an audit trail that cannot be edited.
What breaks at this size is coherence. Sixteen areas built independently become sixteen dialects — sixteen ways to filter, to fail, to ask permission. So the question stopped being how to build each screen and became how few mechanisms the whole product could be built out of.
Architecture
Feature-first, with a small number of shared engines underneath. One wizard engine runs all five multi-step forms. One seeded relational graph backs every screen, behind an awaitable query layer that could be swapped for HTTP without a component knowing. One role matrix resolves into effective grants, and routes, navigation, command-palette entries and individual buttons all derive from it.
One deterministic seed, relational by ID all the way down. Users belong to teams, teams own resources, policies evaluate against live resources, and writes append to the shared audit stream. Nothing is an isolated mock array.
Query modules return hydrated view models over awaitable calls with simulated latency. Offline is raised here rather than in screens, so an outage surfaces through each screen's existing error path and recovers on reconnect.
A seeded role matrix with inheritance resolves into effective grants. Routes, sidebar entries, command-palette actions and individual write buttons all read the grant — no component asks which role is signed in.
Conditional steps, per-step validation gating, dirty tracking and whole-form submit, owned once. Five multi-step forms declare their steps and render their fields; nothing else is duplicated.
// src/lib/backend/queries/session.tsconst ACTION_RANK: Readonly<Record<PermissionAction, number>> = { none: 0, view: 1, edit: 2, override: 3,};The interface
The resources grid is the screen that earns the architecture: sorting, pagination, a nestable filter builder, saved views, grouping, row expansion, bulk actions and drag-to-reorder columns — hand-built, and reachable entirely from the keyboard.
Nestable filter builder, saved views, grouping, row expansion, bulk actions and drag-to-reorder columns — with arrow-key reordering that announces every move.
Switching role in the user menu removes routes, sidebar entries and palette actions. A tab a role cannot use is absent rather than disabled.
Every screen has loading, empty and error states, and optimistic writes roll back with a reason rather than silently reverting.
Performance
Measured against the live deployment with Lighthouse 13 and applied throttling. Desktop scores 100 and mobile 99, both with effectively no blocking time. The finding is an inversion: layout shift is 0.022 on desktop against 0.003 on mobile, which is backwards. The charts measure their container before they draw, so they occupy nothing until a ResizeObserver reports — and the wider the viewport, the further the page moves when they arrive. Hand-building the charts bought zero dependencies and cost this.
Each owning its own view, components, helpers and types
Provisioning, budgets, policies, alert rules and configuration
next, react, react-dom — grid, charts, palette and wizard are hand-written
- Sixteen product areas and no tests. Chrono, one case over, has ninety-six.
- The immutable audit trail is immutable until you refresh. Writes live in memory.
- The shortcuts guide renders from one definitions file. The listener hardcodes its keys and imports none of it.
- Every page title says Helix twice. Thirteen pages append a suffix the root template already adds.