JS Lab
This is a clean-room prototype, not a code demo. The point is to show judgment: tenant context, permission lines, operational state, and interaction design that stays calm under pressure.
What it proves
Flagship Prototype
A clean-room control surface where role gating, tenant context, and product state all shift the UI without the page turning into a gimmick.
Storefront / conversion
Shows script discipline and render-budget thinking where JavaScript weight changes revenue behavior, not just Lighthouse scores.
Access posture
Write access is enabled for incident ownership, release handling, and permission updates in the selected tenant.
Cart script budget
132 KB
Below release threshold
Checkout latency
1.4s
p75 interactive path
Open interventions
3
No blocked releases
Operational queue
Select any item to inspect state, actions, and permission shape.
Activity
Connected to real work
The lab is only useful if it maps back to production experience. These are the real projects that anchor the same concerns.
Storefront performance
94% -> 84% abandoned checkout
The Shopify case study is the real production version of this discipline: script budgets, conversion-sensitive paths, and frontend changes tied to revenue behavior.
Read Shopify case study ->Auth and platform complexity
700k LOC / $7.8k -> $2.4k cloud spend
ACTOR shows the deeper systems side underneath the lab: tenancy, Keycloak, session order, and release risk across a large production codebase.
Read ACTOR case study ->Mobile product delivery
Auth, rewards, messaging, repeatable shipping
The Abantu work matters here because mobile state, messaging, and release discipline change how operations surfaces need to behave.
Read Abantu case study ->Why this matters
That usually means performance discipline, permission clarity, and operational restraint showing up in the product itself. The JS Lab is my compact proof of that working style.