MVP in development
Sutrix
An enterprise OS — a unified operating layer that brings an organization's tools, workflows and data into one coherent system.
Overview
One system instead of a dozen tabs
Most organizations run on a patchwork of disconnected tools — each with its own login, data model and idea of who a "user" is. Sutrix is my answer: an enterprise OS that hosts the pieces an organization runs on as modules over a shared foundation, so data and identity are common rather than copied.
It's early — the MVP is in active development, and this page describes the shape I'm building toward as much as what exists today. AuditFlow is the first product; Sutrix is the platform those products are meant to live on.
Architecture direction
A shell, modules, and a shared core
The design centres on a thin workspace shell that hosts modules registered against a common runtime. Every module reads and writes through one unified data layer and one identity & permission model, which is what turns a bag of tools into an operating system.
The bet: shared identity and data are the hard part — get those right and modules become easy.
Because identity and data are shared, "employee" or "vendor" means the same thing in every module — that's what turns separate tools into an operating system.
Live UI preview
This is the real app, not a mockup
The frame above is the real Sutrix build — same compiled CSS and component markup the product ships — loaded with fabricated data across Identities, Access Requests, and App Studio. Demonstration only, not a connected environment.
Engineering challenges
The hard problems I'm designing around
An extensible shell that stays thin
ProblemA host for many modules tends to accumulate everything and become the bottleneck it was meant to remove.
ApproachA minimal shell plus a clear module contract — capabilities live in modules, not the core.
One data model, many modules
ProblemShared entities are what make an OS an OS — and are exactly where tools normally fragment into silos.
ApproachA unified data layer modules read and write through, so an "employee" or "vendor" means the same thing everywhere.
Permissions across everything
ProblemEvery module needs authorization, but per-module access rules quickly become inconsistent and unsafe.
ApproachA single identity & permission model enforced at the core, inherited by modules rather than reinvented.
Fault isolation between modules
ProblemIf modules share one runtime, a bug in a minor module can crash or corrupt the whole workspace — the opposite of what an OS should offer.
ApproachTreat each module as an isolated unit with a defined contract to the core, so failures are contained and the shell stays up even when one module misbehaves.