WEBTechnologyCA
Nullzec
The interface for an enterprise browser-isolation product — dense security data, kept fast and scannable.
- Our role
- Frontend · UI architecture · Design system
- Platforms
- Web
- React
- Next.js
- TypeScript
- FrontendonlyThe isolation engine is Nullzec’s own
- Dashboard& admin UIPolicies, sessions, audit views
- Virtualisedheavy viewsLarge datasets without a slow scroll
- HandoverreadyBuilt for their team to extend
At a glance
- Business problem
- Nullzec needed a web interface for an enterprise browser-isolation product. The engineering effort was going into the isolation technology itself, and the client-facing application through which the product is configured and monitored needed a dedicated frontend team.
- Technical challenges
- The Nullzec console presents dense security information — policies, live session activity, audit logs — that has to stay legible and fast to scan. Audit views in particular grow without bound, and a naive list renders tens of thousands of rows into the DOM.
- Engineering solution
- WizCodes built the Nullzec frontend as a component-driven React and Next.js application with one design system, virtualising the heavy list views and lazy-loading the rest so the interface stays responsive regardless of data volume.
- Core features
- Client-facing web application UI. Policy management and admin dashboard. Session activity and audit log views. Account, settings and onboarding flows. Reusable design-system component library. Responsive layouts and accessibility passes.
- Architecture
- Next.jsReactTypeScriptAPI Integration
- Technical highlights
- Virtualised list rendering, so audit views stay smooth at volume. Lazy-loaded routes keep the initial console load small. One design system rather than per-screen styling. TypeScript throughout, so the client’s team inherits a checkable codebase.
- Business value
- The Nullzec engagement gave the client a production-grade interface without diverting their own engineers away from the isolation engine. The frontend was built to be handed over and extended by their team.
The problem
Nullzec builds enterprise browser isolation. The hard part of that product is the isolation engine — the thing that actually renders untrusted web content somewhere it cannot hurt you.
But nobody buys an engine. They buy a console: the place an administrator sets policy, watches what is being blocked, and answers the question "why did this request fail" at four in the afternoon with someone from security standing behind them.
That console is a large piece of frontend work, and every hour their team spent on it was an hour not spent on the engine. So they brought in a team for the interface.
Scope and boundaries
This is the section that matters most on this page, so it is worth being exact.
We built the frontend. Nullzec built the product. The isolation engine, the threat model, the infrastructure that makes any of it work — all theirs, all built by their own team, none of it ours. Our scope was the client-facing web application: the screens, the component architecture, the data presentation.
We say this plainly because the alternative is a case study that quietly implies we built browser isolation, which would be false and would not survive one technical conversation.
The API was the boundary. Their engine exposed data; we consumed it. That clean line is what let two teams work in parallel without a standing meeting, and it is usually the thing that decides whether a split like this works at all.
The interesting constraint on a security console is not performance. It is that an operator scanning it at speed must never misread what they are looking at.
How we built it
A component-driven React and Next.js application with a single design system, so a policy screen and an audit screen share the same table, the same status treatment, and the same empty state.
The diagram is deliberately short. That is the whole of our surface — the isolation engine sits behind the API boundary on the right and is not ours to describe.
Two things carry the performance story. Heavy views are virtualised, so an audit log with tens of thousands of entries renders only the rows in the viewport. And routes are lazy-loaded, so opening the console does not pay for every screen in it. Neither is clever; both are the difference between a console that stays usable at volume and one that does not.
Inside the product
- Verdict firstSafe or blocked is the leftmost, highest-contrast element. An operator scanning the column reads outcomes, not domains.
- Domain, unstyledDeliberately plain. Styling it would compete with the verdict for the same glance.
- Per-request timingTabular figures so the numbers align vertically and an outlier is visible without reading any of them.
- Filter, not searchThree states beat a text box here — the question is almost always 'show me the blocked ones', not 'find this domain'.
Colour does one job in this interface and only one: verdict. Nothing else in the feed is green or red, which is what lets a red row register before the operator has read a single word.
What we built
- The client-facing web application UI
- Policy management and admin dashboard screens
- Session activity and audit log views with data visualisation
- Account, settings and onboarding flows
- A reusable, design-system-driven component library
- Responsive layouts and accessibility passes
Written in TypeScript throughout, in the client's repository, structured so their own engineers could pick it up and keep going. That was a requirement from the first conversation, not an afterthought — the point of bringing in a frontend team was to get a console without acquiring a permanent dependency.
If you are considering a similar split, owning your code and avoiding agency lock-in covers the handover side, and our web development work describes how we usually scope it.
Questions buyers ask
Can you build just the frontend for an existing product?
Yes, and it is a common shape of engagement. Nullzec built the isolation engine; we built the interface to it. A clear boundary at the API is usually all that is needed to run the two in parallel.
What happens to the code after handover?
It is yours. We build in your repository, deploy to your accounts, and write it to be extended by whoever picks it up — which for Nullzec meant TypeScript throughout and one design system rather than per-screen styling.
How do you keep a data-heavy dashboard fast?
Mostly by not rendering what nobody is looking at. Virtualised lists, lazy-loaded routes, and pagination at the API boundary do more than any amount of micro-optimisation.
Do you work under NDA on security products?
Yes. Several of our engagements are covered by one, which is why this page describes our scope and approach rather than the client’s internals.