Case study · arch0

arch0

A security platform for infrastructure teams operating under constant risk.

RoleSole Designer
Timeline3 months to v1
ContextCo-founder, product + execution
Team2 co-founder devs · myself
ToolsFigma
Year2023–24

Try it · clickable prototype

prototype · arch0
Interact with it right here, or open it on its own. Open in new tab ↗

Arch0 dealt with highly technical infrastructure data: servers, vulnerabilities, security states, and operational risk. The design challenge wasn't making it pretty — it was helping technical teams detect, prioritize, and act on critical information without creating alert fatigue or cognitive overload. I designed workflows that transformed raw infrastructure data into actionable operational visibility.

The opening: what made this different

Infrastructure teams operate under constant, asymmetrical risk. They're managing sprawling systems, integrating third-party services, and trying to stay ahead of exploits — all while shipping features and scaling under pressure. Traditional security tooling either drowns them in noise (alert fatigue) or forces them to maintain disconnected views across systems.

The harder problem: shifting mindset from "security is nice to have" to "security is non-negotiable." That requires showing, not telling — a concrete product where teams actually encounter risk during their normal work.

Designing inside technical ambiguity

Pivot #1 — Engineers didn't need simpler data

Many enterprise products fail because they "dumb down" technical information for non-experts. That wasn't the problem here. Infrastructure teams understand complexity — they live in it. The goal wasn't simplification. It was navigability and prioritization — that distinction is what separated a useful tool from noise.

The insight: technical depth wasn't the enemy. Unnavigated depth was. Teams needed to see vulnerability density, understand scanning states, and rapidly isolate what matters right now from what to address later.

Constraint #2 — Real-time system complexity

Security and infrastructure data changes constantly. The product had to handle:

  • Data density — thousands of services, hosts, and vulnerabilities across environments
  • Scanning states — in-progress scans, stale data, real-time updates competing for attention
  • Prioritization models — not all vulnerabilities are equal; severity, exploitability, and environmental context matter
  • Hierarchy of criticality — distinguishing a critical vulnerability in production from a similar issue in staging
  • Temporal visibility — understanding when a threat was discovered, when it was scanned, and when it was last seen
  • Alert management — surfacing what changed without interrupting teams or creating alert fatigue

Each of these was a design problem. The platform needed to make this complexity navigable without hiding it.

My direct contribution

I owned

  • End-to-end product design for core workflows (vulnerability discovery, triage, remediation tracking)
  • Data-heavy dashboard architecture that prioritized signal over noise
  • Vulnerability prioritization UX — helping teams quickly assess what matters and why
  • Navigation systems for complex infrastructure states (multi-environment, multi-service visibility)
  • Design collaboration with highly technical engineering teams (translating domain expertise into interaction patterns)

Team contributions

  • Security scanning infrastructure
  • Backend systems and detection logic
  • DevOps integrations
  • Domain expertise that shaped every design decision

The co-founders brought security scanning infrastructure, backend systems, detection logic, and DevOps integrations. That expertise shaped every design decision — I wasn't designing in isolation; I was translating technical possibilities into workflows teams could understand and act on.

Outcomes & traction

What the design delivered

Shipping a working product — however early stage — proved transformative. Instead of explaining a vision, we had something concrete to show. Over 25 clients tried the platform; 2+ converted well ahead of the expected sales cycle. That velocity alone validated the product-first approach.

More importantly, the metrics that mattered for technical teams emerged:

  • Faster vulnerability triage — teams could isolate critical issues in minutes, not hours
  • Reduced time-to-action — visibility led to faster remediation
  • Improved infrastructure visibility — teams discovered gaps they didn't know existed
  • Lower cognitive load for technical operators — complexity was still there, but navigable
  • Increased usability of high-density data environments — teams went deep when it mattered

Reflections

The biggest learning: a working product, however beta, is infinitely more powerful than trying to explain new paradigms to users. Especially in B2B infrastructure, where teams are skeptical of yet another tool, seeing it in action shifts the entire conversation.

What I'd do differently: start with a design system from day one instead of evolving it as the product grew. The constant reworking of components, interactions, and visual patterns as we scaled cost time and effort that a solid foundation would've saved.

The hardest challenge: shifting the mindset from "security is a nice feature to have" to "security is non-negotiable." That required not just good design, but designing in a way that made risk impossible to ignore — embedding it into the workflows teams cared about most, not asking them to care about security on its own terms.