Building a security product while learning the domain and working full time is a coordination problem, not a time problem.
Most solo attempts fail at coordination, not effort. An idea hits. You open a notes app, write two sentences, close it. Three weeks later you cannot remember why it mattered. The research lives in a browser tab you forgot to bookmark. The prototype is in a folder called test3/. Nothing compounds.
The solution is not discipline. It is structure.
Why Identity Security Is Harder to Solo Build Than Most Domains
The attack surface has shifted. Identity is now the primary perimeter. Credential compromise remains the single most common technique behind breaches, turning up in roughly 39% of breach chains. Non-human identities — service accounts, API keys, machine tokens — are proliferating faster than most teams can inventory them.
The tools that address this are either vendor-locked, priced for enterprises with dedicated IAM teams, or both. There is a real gap for a well-scoped, vendor-agnostic identity security product built on open protocols — something that works with any IdP using SAML 2.0, OAuth 2.0, OIDC, and SCIM as the interface layer, with vendor-specific adapters at the edge.
Closing that gap requires being fluent in three things simultaneously: deep identity knowledge (OAuth, SAML, OIDC, SCIM), security product intuition, and the ability to build software. Those three are hard to hold at once. Coordinating them across a full-time role, without a team, is where most attempts break down.
The Architecture: Named Agents, Single Purpose
The answer: treat the work like a small engineering team where each team member is a named AI agent with a narrow scope.
No agent is a generalist. Generalists in multi-agent systems produce mediocre output across the board. Specialists produce excellent output in their lane and hand off clearly.
| Agent | Role | Stage |
|---|---|---|
| Vera | Identity Threat Researcher | Stage 1 — Research Brief |
| Reva | Spec and Architecture Docs | Stage 2 — Product Spec |
| Sage | Content Strategist | All stages, passive |
| Marcus | Backend Engineer | Activates at Stage 4 GO |
| Dani | Identity Security Engineer | Activates when Marcus has shippable code |
| Kai | ML/AI Engineer | Activates when spec requires model work |
| Felix | QA / Adversarial | Activates when there is something to attack |
Most agents start benched. Marcus does not activate until an exploration passes Stage 4 GO and needs code written. Dani activates when Marcus has shippable code that needs hardening. This prevents the system from becoming bloated before there is something worth building.
The Stage Gate: Nothing Advances Without an Artifact
Every idea runs through four stages. Nothing skips.
| Stage | Artifact | Owner |
|---|---|---|
| 0 — Seed | README.md — the raw idea, 1-3 sentences | ahimsauzi |
| 1 — Research Brief | research/brief.md — problem space, existing solutions, gaps, identity relevance | Vera + Lead Dev |
| 2 — Product Spec | spec/product.md — problem statement, target user, value prop, scope boundary, success criteria | Reva |
| 3 — Architecture Spike | architecture/spike.md — feasibility, stack choices, risks, vendor-agnostic checks | Lead Dev |
| 4 — Gate Review | decisions/gate-review.md — GO / PARK / KILL with reasoning | ahimsauzi |
The stage gate is not overhead. It is what converts interesting thoughts into things that can actually be built. If an idea cannot survive a research brief, it was not worth building.
A seed looks like this:
---
date: 2026-05-01 03:25
source: mobile
triaged: 2026-05-17
triage_decision: promote
---
build OAuth2 playground as dev/learning tool inside tools/ directory,
front and back channels flows with live tracers using Python and FastAPIRaw. Unpolished. Enough to reconstruct the intent a month later. That is the only requirement for Stage 0.
What I Did Not Anticipate: Content as a Byproduct
Every research brief Vera produces is the draft of an article. Every architecture spike is the draft of a technical post. Every decision doc is the reasoning behind a future deep dive.
That is what Sage is for. The content layer does not run in parallel with the build layer — it runs on top of it. No separate content calendar. No time blocked for writing. The pipeline artifacts become drafts, and the drafts become posts.
The gap between what Sage produces and what I would write closes over time. The content library builds as a byproduct of the work, not as a separate task.
Security Note
The pipeline itself has a threat surface worth naming.
Seeds may contain design details that should not be public — early-stage thinking on identity security tooling can be sensitive. Remote capture tokens (GitHub PAT, Anthropic API key) need rotation schedules and should never appear in seed content. The content layer has an explicit two-stage gate: drafts are internal only, published requires explicit owner approval. Nothing is automatically posted anywhere.
This is the right way to build identity security tooling: enforce the same principles in your own infrastructure that you plan to build into the product. The pipeline is a proving ground.
