Build the security product from an attacker's eye
Security researcher and CTF player running AISafe Labs
Fineas came to AISafe from offensive security: a researcher and CTF player whose habit was to dive into hard systems and find ways to exploit them. Building a security product on top of that background is an advantage, because the person designing it already knows which assumptions break under a real attack and which ones an attacker walks straight through. Founders who only ever read the documentation tend to protect against the threats they can imagine; founders who spent years attacking understand the threats that actually get used. If your edge is knowing how to break something, the strongest product you can build is the one shaped by that exact knowledge.
Related advice
Choose the market where SaaS competitors cannot follow
AISafe sells into corporate networks, regulated industries, and air-gapped deployments, environments where running as a SaaS is simply not an option. Most security competitors are SaaS-only because it is cheaper and faster to build, which means they physically cannot serve a buyer who needs the tool inside their own network and compliance boundary. Fineas treats that requirement not as a limitation to apologize for but as the moat itself: the constraint that makes the product harder to ship is the same constraint that locks the convenient competitors out. When a market punishes the lazy approach everyone else takes, being the one who does the hard version is the whole advantage.
Sell to procurement and compliance, not just the end user
For AISafe, the people who decide are not only the engineers who would run the tool; they are the procurement and compliance functions that sign off on it. The room made the point concrete on pricing: a corporation of a certain size already has a budget line for your category and a procurement team used to spending it, and those gatekeepers care that the software stays inside their network, respects their compliance boundary, and produces a clean audit trail. Fineas treats them as the actual customer, which means the pitch has to satisfy people who never touch the product but control whether it ships. When you sell into the enterprise, design the demo for the user and the paperwork for procurement, because both have to say yes.
Let the on-prem support reality reshape the whole company
When AISafe runs inside a customer network, Fineas loses live logs, the freedom to hotfix, and any telemetry he did not contractually negotiate. Beyond what that does to the price, it reshapes how the company is built: support has to be staffed for blind debugging, the software has to be written to be diagnosable without a live connection, and the whole engineering culture has to absorb slower, more deliberate releases. Founders selling on-prem should treat the support model as an architectural and organizational decision, not only a pricing input. The way you will have to support the product after the sale should influence how you build the product and the team long before the first contract is signed.
Bring your hardest unanswered question, not a polished pitch
At Indie TM #7, Fineas took the floor with a question rather than a pitch: how do you price an on-prem deployment when the product already works? Because he led with the thing he had genuinely not solved, the room full of people who had shipped enterprise software handed him two concrete answers instead of polite applause for a demo. The reflex to present only the finished, impressive parts wastes the room, because the finished parts do not need help. Walk in with the single hardest open question you have, and let the people who have already been where you are going do the part you cannot do alone.
Extracted from
Selling Security Where SaaS Cannot Follow