Security tooling has a buyer-user mismatch problem that has not been solved despite decades of market iteration. The CISO signs the purchase order. The security engineer has to live with the product. These two people have fundamentally different evaluation criteria. A CISO evaluating a SIEM replacement will prioritise compliance reporting capabilities, executive dashboard readability, vendor SLA terms, and integration with the existing vendor stack they are trying to consolidate. A security engineer evaluating the same product will prioritise query performance on large datasets, the expressiveness of the detection rule language, the quality of the documentation, the API coverage for automation, and whether the product has a CLI or forces everything through a GUI. These are not overlapping criteria. When security startups build their product roadmap around CISO requirements, they tend to produce polished dashboards with weak detection logic and poor automation surfaces. When they build for security engineers, they tend to produce powerful tools with adoption barriers because they have not invested in the packaging and narrative that gets past the procurement gate.
The shift-left movement in application security has exposed a related version of this problem: developer tooling versus security tooling. Static analysis security testing (SAST), software composition analysis (SCA), and infrastructure-as-code security scanning have existed for years, but their adoption in development workflows has historically been limited by three factors. First, false positive rates high enough to erode developer trust quickly — if your tool flags fifty findings on a pull request and forty-two of them are irrelevant to the actual codebase context, developers will start ignoring all fifty. Second, poor IDE integration — scanning results that arrive in a separate portal, disconnected from the developer's active context in VS Code or JetBrains, create a context-switch overhead that gets deprioritised. Third, findings presented without remediation guidance specific enough to act on — telling a developer that a dependency has a known CVE without indicating whether the vulnerable code path is actually reachable in their application is not actionable intelligence.
The founders building developer-first security who get this right share a common characteristic: they have been the frustrated security engineer or developer themselves. They know the specific workflow failure they are solving because they lived it. When we ran diligence on Aikido Security in 2023, the founding team's background in developer tooling was immediately legible in the product decisions: the false positive reduction approach was built on reachability analysis, not just dependency version matching; the IDE plugin was treated as a primary surface, not an afterthought; the alert format was designed to include a specific remediation suggestion with a code example where applicable. These are decisions that come from product empathy with the developer user, not from interviewing CISOs about their desired dashboard layouts.
There is a reasonable counterargument here, and we should engage with it honestly. Building exclusively for the security engineer creates a genuine go-to-market challenge: security engineers do not have budget authority in most organisations. The product might be technically superior and beloved by its users, but if it cannot navigate enterprise procurement, it cannot scale. The companies that have solved this most elegantly are those that use the security engineer as their distribution wedge — bottoms-up adoption that creates enough internal advocacy to get a formal evaluation started — while building the executive reporting and compliance evidence layers that give the CISO a justification framework for the procurement committee. This is a deliberate product architecture choice, not a sales strategy. It requires designing both surfaces from the beginning: the power user interface for the engineer and the governance narrative for the buyer. The companies that try to retrofit one after the other has been built tend to do both poorly.
Our portfolio approach in the developer security category is to back companies that have genuine conviction about the user — companies where the founding team can describe in detail the specific workflow pain they are removing and can demonstrate product decisions that reflect that understanding. Market sizing and TAM models are secondary inputs in our evaluation of this category; the primary signal is whether we believe the team builds security tooling that security engineers will actually want to use, recommend to their colleagues, and fight to keep in their stack when procurement cycles come around.