
Making security simple enough for a startup with no security team
Monolayer is an identity and network security platform that handles end to end access management for you. I am the founding designer and design engineer, and I built the product, the brand, and the design system from zero.
Role
Founding Designer × Design Engineer
Team
Cofounder, with engineers
Duration
Ongoing
Year
2026
00
Overview
Monolayer gives a startup enterprise-grade identity and network security without needing a security team to run it. You tell it what access you need, and it provisions the access, manages the permissions, and configures the underlying network rules for you, across every resource in your cloud.
I joined as the founding designer and a cofounder. I own design end to end: the core product, the interactions, the brand, and the design system, working directly with engineers as part designer and part design engineer. The whole job is one hard thing. Take some of the most complex software in the industry and make it usable by someone who knows nothing about security. Often that someone was me.
0 → 1
foundingdesign
5
designpartners
3
lettersof intent
0
securityexpertise
01
Too many tools. Too many permissions.
Identity has splintered across IAM, 2FA, ZTNA, and agentic tools. Each one has its own console, its own rules, and its own blind spots. For a startup with no security team, stitching them together safely is close to impossible.
75%
of companies had a SaaS security incident last year
29M
API keys leaked on GitHub in 2025
41%
of breaches traced to permission mismanagement
01
A separate tool for everything
Logins, network, devices: a different tool for each, and none of them connect.
02
Too many ways to slip up
Thousands of settings decide who gets access. One wrong choice opens a door.
03
AI agents move too fast to check
Agents act on their own, faster than anyone can review. One wrong grant, real damage.
04
Rules that fall behind
Threats change by the second. Access rules sit untouched for months.
All of this was built for security experts, and even they struggle with it. In an era where anyone can build, that no longer works. Security has to be for everyone.
The old way
Built for experts
Every security tool assumes a specialist on the team. Even the experts find them painful, and most teams do not have one.
Monolayer
Built for everyone
Anyone who builds can secure what they ship, with no security expertise required.
02
Who it's for
Monolayer is built for the teams that need security the most and have the least help with it. The person setting it up understands their own systems, but is not a security expert, and the product is designed so they never have to be.
Company
Seed to Series B AI startups, and growth-stage, cloud-native teams.
The moment
Racing toward their first SOC 2, and they need security in place fast.
Who sets it up
The CTO or an engineer on the team.
Their expertise
Deep in their own systems, but not in security.
What is missing
No security team, and no plan to hire one yet.
03
What I owned as founding designer
I built the product from nothing. There was no design team, no system, and for most of what I designed, no existing pattern anywhere to copy. I also work as a design engineer, prototyping and building interactions alongside the engineering team rather than handing off static files.
Core product & interactions
Every core function and flow in the product, designed and prototyped from the ground up.
Interactive access map
A visualized, animated graph that makes a company's entire access landscape readable at a glance.
Natural-language access
Adding resources, access, packages, and services by stating intent in plain language, paired with live visualizations.
Access requests
A requests view for approving access fast, with all the context an approver needs to decide safely.
AI security agent
A prototype agent that turns a prompt into security actions and executes them under human approval.
Brand, design system & site
The Monolayer brand, the design system everything is built on, and the marketing site.
04
Learning security from zero
I knew nothing about security when I started. That turned out to be the point.
Before designing anything, I spent long sessions with my cofounder, who walked me through the security problems, the real scenarios, and the underlying principles in plain language. I asked an enormous number of questions, then went and learned the concepts on my own until the terms and processes were clear enough to design around.
The insight that shaped everything
Me
A designer who knew nothing about security
Our user
The builder we were designing it for
So if I could understand it, so could they. My confusion was the most accurate user research we had.
05
Taming the complexity
The work was a series of the same problem. Take something that normally requires an expert and several tools, and turn it into one clear action a non-expert can take with confidence. Here are the ones I am proudest of.
01
Granting access, written like a sentence
Granting access is the core job and traditionally the most painful, normally meaning a hop between platforms and a fight with complex configuration UIs. There was no framework to follow, so I designed the flow around plain language: you compose the action as a sentence, grant someone a role on a resource, filling in or selecting each parameter so it always reads the way a person would say it. Alongside it, a live visualization shows exactly what the action will do before you commit.

02
An access map you can actually read
A company's access landscape is a dense web of resources, roles, and relationships. There was so much that could go on the map that I stalled, and honestly procrastinated, because I had no good way in. The unlock came from mentors with enterprise UX experience: start from the user's goal and the information they actually need, not from everything you could show. I sat with the product and engineering teams to learn how they would use the view and what they needed from it, then prototyped directly into an interactive, animated graph that makes a complex access structure legible at a glance.

03
Approving access with full context
When someone requests access, the approver needs enough context to decide safely. I designed a requests view that surfaces who is asking, for what, and why it matters, so approvals are fast and informed rather than rubber-stamped.

04
An AI security agent, under human control
I prototyped an AI security agent that turns a plain prompt into a concrete plan of security actions, then carries them out, always under human approval and supervision. It pushes the core idea further: the human stays in control and understands every step, while the hard, repetitive work is automated.

06
Where it is now
Monolayer is a working product with real traction. We have five design partners actively iterating with us and three letters of intent, and we are preparing to scale.
5 design partners
Real teams using the product and shaping each iteration with direct feedback.
3 letters of intent
Early commitments from companies that want what we are building.
Built and working
Not a concept. A real, functioning platform, ready to scale into sales.
07
What I learned
Founding the design for a product this complex taught me as much about how to think as about what to draw.
01
Being the newcomer is a design tool
In a complex domain, the person who knows nothing is the most honest stand-in for your user. I learned to treat my own confusion as data, not a weakness to hide.
02
Start from the goal, not the complexity
The access map only worked once I designed from what users needed to know, not from everything the system could show. Restraint was the real unlock.
03
Invent the flow when none exists
Most of this product had no pattern to copy. I learned to design transformative flows from first principles, grounded in the real process and the user's intent.
04
Design and build together
Working as a design engineer alongside the team let me prototype real interactions instead of pictures of them, and ship a product that genuinely works.