Why I'm democratizing security testing

In the past 2 weeks I didn't ship a single new agent or detection capability. The scanner barely moved. Instead I focused on everything that wraps it: the product's website, intake form, Stripe checkout, domain authorization flows and the AWS infrastructure hosting it all.

That was a deliberate choice. And it's worth explaining why, because the choice came from a frustration I've been sitting with since I started this project.

The landscape is moving faster than people can keep up with

The pace of new attacks is genuinely overwhelming right now. AI is accelerating both sides of the equation. Attackers are using AI to scale attack discovery, automate reconnaissance, and probe applications at volumes that didn't exist two years ago. Defenders are using AI to keep up. And the gap between what a sophisticated attacker can do today and what a small dev team can reasonably defend against is widening.

Even seasoned security professionals struggle to keep up with the shape of what's emerging. New attack categories like prompt injection and indirect retrieval poisoning didn't have names eighteen months ago. The OWASP API Top 10 has been substantially rewritten twice in the past few years. Tooling that was state of the art three years ago is now table stakes, and tooling that's state of the art today will be table stakes by the time most teams adopt it.

What this means to small dev teams

For a small dev team running a SaaS product, the situation is worse. They're being asked by enterprise customers to prove security postures their teams aren't sized to maintain. They're seeing real intrusion attempts in their logs. They don't have a security person, often don't have anyone whose full-time job touches security, and the manual options for testing their app cost $15,000 and arrive months late.

That's the gap I'm trying to close. Not by being a marginally cheaper version of the manual pentest, but by making rigorous security testing genuinely accessible to teams that have been priced out of it entirely.

Removing friction

The pentesting friction points I've watched up close: scoping calls that take two weeks to schedule. Procurement processes that need a security questionnaire of their own. Legal questions about authorization to scan. Credential exchanges over email or Slack that put plaintext passwords in places they shouldn't be. Infrastructure setup that requires a security engineer the customer doesn't have. Status updates that arrive over phone calls and PDF attachments.

Each of those is a tax on accessibility and security. Each one looks like nothing on its own, and together they're the reason a small dev team can't just decide on a Tuesday that they want a pentest done by Friday.

The weeks I just spent were on removing those taxes. The flow is now: sign up with an email, fill out a structured intake, pay $500 through Stripe, prove domain control through DNS or a well-known file, share a test account through end-to-end encrypted credential exchange: scan queued. Each step is self-serve, takes minutes rather than days, and asks only the information the scanner genuinely needs.

What I still do by hand

I want to be honest about where the product is today versus where it's going. The funnel is built but not yet open to the public. Right now I sit in the middle of every scan. I review the queue, monitor the scanner as it runs, and check the report before it goes to the customer. The plan is to open the funnel to a small number of early customers first, so I can keep that loop tight while the scanner earns its trust.

That's deliberate. The reports need to be solid, and the only way I'm confident in that yet is by checking each one. Every customer engagement is also still teaching me where the scanner produces noise, where the deliverable could be sharper, and which controls customers actually care about.

The end goal is different. I want a small dev team to be able to run their own pentest at 1am in the morning, get a real report back by noon, fix what needs fixing, and run it again the next week. No human in the loop. No scheduling. No conversation with a vendor. Just a tool they can rely on the way they rely on their linter or their CI pipeline.

That requires a lot more confidence in the scanner than I have today, and a lot more confidence the deliverable holds up across customers I haven't met. Both will come. But the funnel had to be built first, because none of the rest matters if the customer can't actually get to the scanner without two weeks of friction.

Why this all mattered

The weeks I spent on the funnel didn't add any new capability the scanner couldn't already do. But it did something more important: it turned what I've been building from a tool into something a customer can actually buy. The site opens soon. When it does, the next time I write about a new detection or a clever piece of agent design, it'll be because someone paid five hundred dollars to have it run on their app or API, and that money is now on the other side of a flow that takes them ten minutes instead of three weeks.

‍

Week 9 next Tuesday.