Role-specific experiences, without forking your frontend. Each role gets its own view. You keep every rule.
SDK alpha in development · design partners first · enterprise contracts planned
My work
JKA assignIllustrative product. Switch roles, then open Billing: the locked screen is identical for everyone.
Every customer wants a simpler view for someone. One wants stripped-back, another dense. Forking the frontend for each never stops being expensive.
Role presets. A role’s starting layout, density, wording and guidance, which each person adjusts within your policy.
One codebase. No fork per role or customer. Presets are configuration; your standard view stays one action away.
Locked screens. Billing, security, consent and compliance screens are declared in your manifest, never re-rendered, for any role.
Your design system, intact. Design tokens, component registry and permitted layouts are yours. People choose within them.
Logic stays in your backend. Data, business rules and permission checks never move. Your API decides who may do what.
Rollout, audit and rollback. Percentage rollouts, pinned template versions, a kill switch, and one content-free audit event for every change.
Vendor control
You set the rules. OwnUX works inside them.
Decide which layouts are allowed, which screens are locked and which template version runs. Unpermitted preferences fall back to ones you allow. A kill switch hands every surface back.
- Locked screens never render as OwnUX surfaces.
- Template versions are pinned, so nothing changes unannounced.
- Policy-checked: known components, valid properties, available actions, one switch back.
Acme Service · OwnUX policy
templates pinned · v1Design tokens
Permitted layouts
Locked screens
What each person gets Example profiles
Sam prefers table
Gets table
Rahi prefers board
Gets board
Priya prefers list
Gets list
Illustrative policy. Turn a layout off, lock a screen or flip the kill switch.
Conformance
Declared once. Checked before every release.
The ownux test command checks your manifest, then runs every action against staging: execute, verify, fall back, and refuse safely when permission is denied. Publishing is blocked until it passes.
- L1 Declared: valid manifest. Until then, OwnUX stays off.
- L2 Verified: actions pass execute, verify, fallback and permission-denial tests.
- L3 Adaptive (automated accessibility checks) is planned for the beta.
$ npx ownux test --config src/ownux/ownux.config.ts ✓ Manifest valid L1 Declared ✓ Locked: billing, security, consent ✓ Reads return the right tasks, in the right workspace ✓ Writes execute, verify by reading back, and fall back ✓ Permission-denied paths are safe L2 Verified Publishable: yesWhat Satin will receive, and what it never does. The runtime runs in your frontend, and your users’ data flows as it does today. Satin’s cloud isn’t hosted yet; when it launches, this is all it receives.
Pseudonymous counts. Licence and metering counts use a hash of product and user IDs, never the IDs themselves.
Aggregate analytics, if you opt in. Only what you choose to share, in aggregate, to compare adapted users with your holdout.
Never your users’ content. Satin’s cloud never receives your end users’ records, documents or messages.
Where things stand, and what enterprise teams ask.
In developmentThe OwnUX SDK alpha for React, with locked screens, pinned templates, percentage rollout, holdout and kill switch, running in the Reference App.
PlannedComplex enterprise applications such as CRM and ERP. The first design partners we’re looking for are work-management products.
PlannedAn Enterprise plan with an SLA, SSO, dedicated support, security reviews and data-processing terms.
Guidance layers add tours and tooltips on top of one fixed interface. OwnUX changes the interface itself for each person, from your own components and within your rules, and verifies every action against your API.