Selling Security Where SaaS Cannot Follow

I spent years as a security researcher and CTF player, which is a polite way of saying I spent years diving headfirst into the hardest subjects to find ways to exploit them. These days I run AISafe Labs and ship AISafe, a security product. The part that shapes everything is where we sell it: not as a SaaS anyone can sign up for, but into corporate networks, regulated industries, and air-gapped deployments, the places where running someone else’s cloud service is simply not an option.

When I took the floor at Indie TM #7 in Timisoara, I did not bring a pitch. I brought a question: how do you price an on-prem deployment? The product works. What I had not figured out was what it should cost to put it inside a customer’s own network, behind their own compliance boundary, with their own audit trail. The room had concrete answers on the pricing math, but the more interesting conversation, for me, was everything around that question: why this market, why this background, and what selling into it does to the company you build.

The constraint is the moat

Most security tools today run as SaaS, because it is cheaper and faster to build. That model works beautifully right up until your customer is a corporation that wants the tool inside its own four walls: its own network, its own compliance boundary, its own audit trail. For a SaaS competitor, that requirement is a wall they cannot climb without rebuilding their whole company. For us, it is the front door. We sell into the market where running as a SaaS is not an option, and the exact constraint that makes the work harder is the same constraint that keeps the easy competitors out.

Building security from an attacker’s eye

I did not arrive at security through theory. I arrived through years of breaking things, of diving headfirst into the hardest subjects specifically to find how they could be exploited. That offensive instinct, the CTF habit of asking “where does this fall apart,” is not a detour from building a security product, it is the foundation of it. When you have spent your career attacking systems, you know exactly which assumptions a defender quietly makes and which ones an attacker will walk straight through. That background shapes AISafe far more than any feature checklist could, because the product is built by someone who has spent years on the other side of it.

You are selling to procurement, not just the engineer

In a SaaS world the buyer and the user are often the same person clicking “start free trial.” Selling into corporations is not like that, and the room made it concrete when the pricing conversation turned to budgets. A corporation of a certain size already has a budget line for tools in our category and a procurement team that is used to spending it. The people who decide are not only the engineers who would run AISafe; they are the procurement and compliance functions that care the tool stays inside their own network, respects their compliance boundary, and leaves a clean audit trail. They speak the language of risk, budget, and control rather than features, and learning to sell to them is a completely different skill from impressing the person who will actually use the software.

The support reality reshapes the whole company

Here is the part that surprised me most, and the thing that turned a pricing question into a company-design question. Once your software lives inside a customer’s network, you lose almost everything you take for granted in SaaS. No live logs without a ticket. No quiet hotfix without their change window. No telemetry at all unless you negotiated it into the contract. That changes far more than a price tag. It changes how you staff support, how you write the software so it can be debugged blind, how you ship updates, and how patient your whole engineering culture has to be. The on-prem support reality is not a line item you bolt on at the end, it is a force that quietly redesigns the company around it.

Bring the question, not the pitch

I want to be honest about how that evening actually went, because it is the real lesson. I did not stand up with a deck and a closing line. I stood up with the one thing I genuinely had not solved: how to price an on-prem deployment when the product already works. Putting that unfinished question in front of a room of people who had shipped to enterprise customers got me two sharp answers that I would have circled for weeks on my own. The instinct to only present what is polished is exactly backwards. The polished parts do not need the room. The unsolved one does.

What the pricing question was really about

I left the meetup with the pricing math I came for, but the bigger takeaway was that none of these threads are separate. Choosing the market where SaaS cannot follow, building from an attacker’s background, selling to compliance, and designing the company around blind support are all the same decision seen from different angles. The on-prem price tag I still had to finish working out is just the most visible edge of a company shaped, top to bottom, by selling security exactly where the easy competitors are not allowed to go.