LayerV · 2026 – present · Design Consultant
LayerV
Translating a new kind of security technology into surfaces that people and AI agents can actually adopt.
What LayerV does
Most security guards a door everyone can still see. LayerV removes the door. Your app or API only ever dials out, so nothing on the internet can find it or call in. When someone needs access, a person or an AI agent, they get a link that opens the door for them, for that session, and then it’s gone again.
Guard a door
A login in front of an open port.
- The port still answers
- Scanners find it
- Attacks now run at machine speed
Remove the door
Nothing answers a stranger.
- No open port, no public DNS
- Access is a link, not a login
- Agents and people use the same path
Under the hood it is new and genuinely complex: an open network-hiding protocol, a connector that holds an outbound session, cryptographic resource IDs, links whose secret never leaves the browser, SDKs in three languages, an MCP server, and a CLI. None of that is what a customer needs to understand first.
My role
I work with the founding team on go-to-market and product-market fit, and in practice that means one thing: translating complex, new technology into surfaces people and agents can adopt. The website, the docs, the developer paths, the skill file an agent reads, the words on every button.
The team builds fast and builds with AI. That is the right call for a startup, and it comes with a cost. Building at speed leads to a variety of mistakes and misses: a page that describes a feature that moved, a code sample that no longer runs, five install paths presented as equals when one of them is the easy one, a concept with four names. My role is to steward excellent design and accuracy for both humans and agents to ingest on the platform.
Making it understandable
The first thing I did was learn the technology properly, from the repositories rather than the marketing, so I could explain it without hedging. That produced the model everything else hangs off: every path does the same two jobs. Hide it (something next to your app phones out to LayerV) and let someone in (mint a link). Once you can hold that, the CLI, the connector, the SDKs and the MCP server stop being a menu and become answers to “where does your app live and who needs to reach it.”
- Your appstays on localhost or in your VPC
- Connector or CLIdials out, holds the session
- LayerVnothing answers until a valid link arrives
- Linkexpires, one-time, per person or agent
- Person or agentin for the session, then gone
From there the surfaces changed to match the model. The easiest path leads. Setup starts from what you are trying to do, not from which tool to pick. Implementation steps show what gets removed, a port or an ingress, because invisibility is a deletion and the diagram should say so. Names were cut down to one per thing.
Making it adoptable by agents
A growing share of the people setting up LayerV are not people. They are coding agents acting on a one-line instruction. So the platform has to be legible to a model as well as a reader: a skill file an agent can load, install snippets that are exactly right, no ambiguity between a resource and a link, and plain language that survives being paraphrased by Claude. I treat the agent as a first-class user and test the paths the way an agent would follow them.
Two audiences, two front doors
LayerV sells to security teams and platform engineers. qurl.link is for someone who just built something and wants to share it privately. Trying to speak to both on one site meant neither recognised themselves, so the story split. layerv.ai became the enterprise and team home, with the platform, the connector, trust and a pilot path laid out for a buyer’s questions. qurl.link became its own product experience, designed to make the technology feel like magic.
Where it is
Early, and live. Both sites are up, the positioning is landing, and the next few months are about finding which use case pulls hardest, agent access in particular. I’ll expand this as the work matures.