Onkar Muḷē
Selling Truth

Building a Security Business in the Age of AI.

On market conditions, moats, revenue mix, ICPs, pricing, and the BD function for a security firm navigating the AI era.

Onkar Muḷē

Part IWhat the Market Rewards

01Market Conditions and Competition

Crypto has not been in a favorable state over the last 18 months. We have seen far fewer new protocols launched, and have heard shutdown news from well regarded teams, including some of the most favored protocols in the space.

Two significant shifts stand out against this backdrop. First (macro), activity is consolidating around stablecoins, tokenization and agentic payments as key parts of the sector. Second (micro), AI-powered security tooling is on the rise, alongside privately run LLMs fine-tuned on top of publicly available data.

When I see these announcements, personally speaking my read is that much of it is hype driven and conditions are still not favorable for most companies. What is actually happening is that companies are trying to make the category feel exciting to aid narratives for raising capital. Contrast that with how newer firms operate by expanding market presence through marketing, events and a deliberately built brand, and in turn developing brand equity in a way that was simply not seen in how cybersecurity companies did business in the previous decade.

Yet, what we do know is that security purchasing runs on trust, and that trust is slow to earn and easy to lose. Making a purchasing decision in security is close to a leap of faith for the team, especially when you're a new firm in the market and the customer is really asking whether this partner will stay on top of issues neither side can foresee at signing. That's why security sales carry long cycles, in-depth trials, and small initial deployments, and it is also why a security company cannot simply blitzscale its way to market share.

Trust is the one advantage which compounds with time and cannot be bought.

02Moat and Margins

On AI-powered tooling built on top of foundational models, there is no moat. What if there is no immediate moat? What if the moat is earned? Two types of moats are about to emerge.

Leading moats exist at founding by having technical differentiation or a proprietary dataset. Lagging moats are earned through years of execution with economies of scale, brand, channel relationships, embedded workflows.

The second type of moat cannot be drawn on a competitive landscape matrix because it's not built yet.

As of now, nobody in the security market is building a foundation model, which is not easy or convenient at all given the compute and capital required. Yet, what a security company can do is build better harnesses than the next firm and make inference cheaper and more efficient. That's what teams are fighting for: margins.

Cursor is the instructive example. Cursor delivered a better user experience than Devin did, and Devin's first impression was not sticky. Cursor kept improving at fine-tuning existing foundation models for development-centric work, and yet they lacked compute, which is one of the reasons they went down the acquisition route.

Why? The next foundation model will not necessarily gain anything from past harness work, so harness engineering can sometimes be a waste of engineering hours and capital, because the next frontier model can simply absorb what the harness was doing.

Harnesses augment a model's capabilities, but as new models are released, a lot of what people built to augment them becomes redundant or gets constrained by the model's own improved capabilities. I would not say we should avoid harnesses completely, but it does mean the most obvious ideas for how to construct a harness have a shelf life, and they will become obsolete faster than we think.

That said, I still believe in a case for harnesses. A harness adapts to exploit new capabilities and makes them maximally useful to the end consumer. Every major model advance opens more doors than it closes, so new agentic tasks become possible faster than old ones become obsolete. That is where a harness provides a consistent interface to whatever the bleeding-edge capabilities are. Beyond that, harnesses deliver the usual software usability gains:

Harnesses are about making model capability maximally useful, effective, consistent, and accessible.

There are a few more concepts I want to get deeper into before I can say more, and many open questions remain: does fine-tuning on small sets of data actually work well?

Part IIWhat We Sell and Who We Sell To

03Revenue Mix and Where AI-Powered Security Tooling Fits

Revenue mix can span four service lines: audits, validator operations, retainers (rolling commit reviews), and training (OpSec, IR).

AI-powered security tooling will shape how we structure business development from here. As an external product, the tooling works as a pipeline generation engine by default. It attaches naturally to audits, for example in pre-audits where AI scans surface vulnerabilities the models are capable of catching.

04Delivery Model: Bundling, Managed Services, and First-Party Selling

It helps to be clear about which delivery model we are running, because teams tend to fall into one of three.

A security firm can operate across the first two: audits and retainers are the "we secure you" outcome, while AI-powered security tooling is closer to "we give you the tools." I believe naming this matters because the tools model tends to attract exactly the mature teams who also run a build-or-buy assessment every time they hit an unmet need, which is a competitive dynamic worth designing around instead of discovering late.

Exploring how we grow AI-powered security tooling, I think the first move of interest is bundling it with existing solutions, meaning audits. Bundling gives us a natural vehicle for trials and testing in live service engagements, because it is natural for teams to accept something that is free, or lightly priced for premium versions, and let us run it inside their environment.

There is a productizing opportunity in the services themselves by packaging what we do into well-defined, clearly scoped, predictably priced offerings, rather than offering bespoke quotes every time, borrowing the parts of a product motion that make buying easier while keeping the delivery human. To a degree, our operating model then has two components where we act as a managed service provider, and we act as a value-added seller of our own product.

05ICP and Segmentation

Segmentation in security does not follow the usual pattern, and it is worth being explicit about why. In most industries adoption flows from SMBs up to enterprise, but security runs this in reverse. Most mature, best-resourced customers adopt first, because they have the most to protect and the in-house talent to evaluate a new partner, while smaller teams tend to buy well-understood solutions later, if at all. This inversion has a direct consequence for how we sequence our efforts.

For the audit and retainer business, the center of gravity is the mid-market of serious protocols and well-funded teams over the largest enterprises on day one. Landing enterprise and institutional accounts is the direction we grow toward as the function matures and our references improve. Mid-market teams have budgets, they consistently deploy code (a sign of reliable engineering cycles), cannot afford to lose user funds, and they move faster through procurement than an institution or enterprise will. I believe the near-term ICP question is not whether to chase enterprise, but which sub-category of the funded mid-market (high TVL protocols, actively building DeFi teams, staking and infrastructure operators) gives us the highest concentration of accounts where existing reputation and proof-of-work does half the selling.

Sensible structure remains a two-tier motion: sales-led growth, complemented by product-led growth as a continuum. Defend and grow the core with audit and retainer engagements aimed at mid-market teams, and serve the longer tail and earlier-stage teams through the tooling (at least while in beta). How far the tooling can carry a self-serve motion is one of the genuinely open questions, rather than something I want to assert before we have tested it.

06Which Segment to Sell To

The segmentation question is which customer we sell to directly, and each type buys differently. Three familiar buckets are individuals, small and mid-sized businesses, and enterprises. None of the pure endpoints is where we start.

Selling security to individuals (security engineers, smart contract devs) is barely a market. Selling to the smallest and least mature teams runs into a wall because they often do not understand their own security risk, and so they are not looking to pay a premium for it, which means the motion will become an education initiative before it becomes a sale, leading to a lengthy sales cycle.

Enterprise and institutional customers have the budget and the regulatory pull, but they move slowly and demand a level of proof and relationship that a freshly rebuilt BD function should grow into rather than open on.

This follows two implications. First, the realistic near-term target is the funded mid-market of serious protocols and teams, a segment that grasps its own risk, has budget, and moves at a workable pace. Second, if we do want to reach the smaller and earlier end of the market, the efficient path is almost certainly not direct outbound to teams that need educating, but through intermediaries who already hold the relationship: the Web3 equivalent of managed service providers and vCISOs, meaning ecosystem teams, accelerators, foundations, and studios who can vouch for us.

A B2B2C route, where the entity building the product effectively covers security for the teams downstream of it, is an interesting variant of the same idea and worth exploring once the core mid-market motion is working. For any of these, the groundwork is the same, and I want us to answer honestly: how many prospects we have, are we asking them the right questions, and do we ourselves have the right questions framed about the tooling.

07Build or Buy

As we define our ICPs, the question every target account will ask itself is build or buy. Will they build the tooling in house, or are they comfortable buying or outsourcing it?

Foundation models are openly available, so what the work actually requires is fine-tuning. For the customer, what's worth asking is whether they have the capital to hire ML engineers and build from scratch, which takes far more time and capital, or to work with an external provider.

Even with how we roll out the product, a sensible response is to expose enough of the tooling for a prospect to feel the value while keeping the deeper capability behind vetting, alongside the agreements that protect us from misuse.

08Differentiation Objection

What's our unique value proposition? What exactly are we providing that is different? Have we fine-tuned, is the inference better, or is the output materially stronger? Prospects will be using Cursor, Claude, ChatGPT, Codex, and similar tools, and the more sophisticated the customer, the more likely they are to run a build-or-buy assessment and simply task their own team with something internal, spending only what compute costs.

The answer cannot be more dashboards or a bigger claim.

Value is whatever the customer actually cares about, and a tool proves its worth by getting a user to a real result fast, ideally showing them in minutes something that used to take days of manual review. Short time to that first result is itself the differentiator, and it is what cuts through the cynicism of a market that has heard every security pitch.

On reflection, the build-or-buy objection is hardest with the most mature, best-resourced teams, the ones who can staff an internal effort. It's far less relevant with the funded mid-market teams who have systems to protect and would rather not stand up a security research function of their own yet. For them the compelling offer is less a raw tool and more a full-stack security relationship, where we support deployment, post-deployment monitoring, and continuous coverage on top through the tooling. It's the offer shape that fits the segment we are targeting first.

Part IIICommercial Architecture, Pricing, Motion, and Channel

09Basic Mistakes to Avoid

Not having a data-driven pricing model and picking up the wrong growth motion with a "build it, and customers will come" mentality. What's most used by teams so far is a subscription-based model, yet subscription tiers have to be designed around actual customer personas, specifically who we are selling to and whether they genuinely need it.

What I know from people watching the space is that the standard play is a freemium and premium tier structure. That lets prospects experiment with minimal capital committed and grow usage from there, which is the core of good onboarding.

10Packaging and Pricing Architecture

Packaging is the hard part. Benchmarking how other security firms price their tooling: the pattern is light scan vs. pro scan tiers with credit-based metering that controls how far users can experiment. We need an entry-level tier priced low enough to remove friction at signup, and cheap enough to operate that it does not strain us, since I assume we are not sitting on venture-scale funding to burn through.

Low entry pricing might be the right call, but the shape of the free entry point should follow the product. A time-boxed full-featured trial fits when a user can reach value quickly and get the full picture from a single instance. A feature-limited free tier with no time limit fits when the value only shows up at scale and we want practitioners to run it in a home lab or on a small repo before committing. Which of these suits the product depends on how fast a user reaches a first useful result.

I would also resist making pricing fully public before we understand our own margins and go-to-market. Transparent pricing has real virtues in a market tired of "request a quote," and it helps the team trying to build an internal case, but it also sets an anchor that enterprise procurement will negotiate down from, it can foreclose channel margins, and it locks us in before we have learned what people will actually pay.

We can go down the disciplined path by running test arrangements privately with selected customers, watching what it does to margin, retention, and conversion, and opening up only once we have confidence.

The product could operate as a lead engine that feeds the services pipeline too. I advised a team on a similar motion where the product served as the onboarding layer. Users experimented on the free tier and converted to enterprise once fit was established, with enterprise meaning internal team usage plus servicing their own clients, audits, and retainers. So the ladder for the product runs free tier, then paid, then enterprise expansion wherever the upsell case holds, with the free-to-paid step made as frictionless as possible while still creating a natural moment for our team to introduce the audit offerings that fit.

Price points get defended with utilization math, which keeps the conversation value-based instead of cost-plus.

11Motions and Channel Discipline

Each product carries its own mix of product-led and sales-led motion, and I want to be careful about how those two words get used. Product-led growth in security is not a switch we flip, and it is never a substitute for sales. It is a continuum, and in a trust-driven market it works best as a complement to a sales-led motion, shortening the time it takes a deal to close and opening a channel we do not have today, rather than replacing the relationship selling that audits will always require.

Concretely, that means not opening the product to ungated self-signup on day one. A staged path: start with a self-serve signup that we approve manually, learn who is actually showing up and whether the need is real; then open a fully self-serve trial experience with a contact-sales path on the upgrade so we can learn pricing against customers' willingness to pay; and only move to fully self-serve billing once we understand what makes users convert.

There are a few questions that sit genuinely open here, and I would rather flag them than pretend I have settled them. First, is the product well suited to a product-led motion at all? Products that carry PLG well are easy to understand, easy to evaluate, and fast to reach a first moment of value, and how quickly a prospect can reach that moment inside the product is something we need to measure. Second, where exactly the handoff sits between a self-serve product motion and a sales-led audit and retainer motion, so that the tooling feeds the services pipeline and doesn't end up competing with it.

Operationally, my preference is fewer channels with clear removal criteria. If a channel is not producing results within its window, we shut it down fast and rotate in the next experiment.

12Strategic and Channel Partnerships

After direct selling, there is how we position ourselves and how we grow strategic partnerships, and channel is where scale eventually comes from in security. In the broader cybersecurity market the overwhelming majority of spend flows through partners over direct sales, and while Web3 has its own ecosystem, we cannot reach every team building across the ecosystem simply through outbound.

Channel is a strategic choice we have to make early because of pricing decisions. Fully transparent public pricing makes it hard for a partner to earn a margin. Pricing set too low gives a partner no incentive to push the offering. So how we price the product and package our services has to be decided with the channel question already in view.

Naturally, our partners here are development studios and ecosystem teams, especially their accelerators, that already hold trusted relationships with the builders we want to reach. They have similar standing to managed service providers or vCISOs in traditional security: a trusted intermediary who can vouch for a security partner to a team, which helps in reducing time-to-trust. Collaboration makes sense where it aligns with our values and with how we weigh competition versus collaboration in this market.

On the marketplace angle, listing our services where teams already transact, whether AWS Marketplace, Google Cloud, or ecosystem-specific venues, follows the same data-gravity logic reshaping security distribution. Customers find it easier to enable something adjacent to where they already operate than to run a fresh procurement. I believe the direction of travel in security services is toward full-stack providers who are both strategic and deeply technical and who stay with a client across the whole lifecycle rather than handing off between strategy, implementation, and monitoring. A combination of audits, tooling, and live infrastructure operations is well-suited to that shape, and it is a genuine differentiator worth building the partnership strategy around.

Part IVBuilding the BD Function

13What the Function Is Made Of

What matters? We need three components in order: a data foundation, pipeline stages, and an operating system, including messaging, tooling, and cadence, that keeps it all moving.

Data before process. We start by understanding what customer and pipeline data already exists, in whatever form it takes. A firm that has operated for years accumulates a great deal, most of it likely held informally, in people's heads, inboxes, groups, and past engagement history rather than in a CRM. The first task is to audit what we have, see what shape it is in, and design the systems we need to build on top of it, because without a clear view of existing relationships and history there is no context for running revenue ops.

This is the pattern I see constantly in consulting engagements where teams ask how to improve forecasting, and my honest answer is: without a data foundation, without consistent capture and regular analysis, and without a clear view of what to collect, no forecast will hold.

Beneath all of it sits the data layer: aggregating activity from Telegram, Slack, and Gmail into Salesforce or HubSpot with consistent data entry. When the system pulls everything into a single source of truth, it feeds the sales forecast, gives a true view of business health, and supports scaling decisions.

Stage one: personas and ICPs. Everything downstream depends on knowing who we sell to. Before any qualification can happen, personas need defining and the ICPs need to be ready, so that the rest of the pipeline runs against a deliberate target list rather than whoever happens to show up.

Stage two: qualification. Qualification is necessary, because most deals are not won or lost on the final call or at the last stage of the pipeline. They are decided at the start. My working hypothesis from lost deal data is that most losses trace back to weak qualification at the top of the funnel, not to pricing and not to proof of work. Tightening qualification discipline, whether through MEDDICC or a lighter framework, should move win rates more than any discounting would.

Stage three: discovery. Having a proper discovery process establishes where the prospect stands and whether expectations are being met on both sides. It also doubles as reflection on our own services, since every discovery call tells us something about how the market perceives what we deliver, in turn helping us improve our positioning and propositions.

Stage four: problem solving. When we surface problems, our job is solving them, and if qualification was done right the problem-solving sessions get much easier because a mutual working understanding already exists. The reason clients engage a security firm is that they cannot afford loss of user funds once the codebase ships to production. Even in bad times, they need to trust that when incident response is required, we understand their codebase well enough to execute safety measures, that we have a capable incident response team and a genuine relationship. They need to be able to rely on us in hard moments; our job is never to let those times befall our clients.

Stage five: closing. With problems surfaced and solutions presented, closing becomes close to a formality. Closing depends on landing the right price point. Discovery is about surfacing problems through the right questions, and it is our judgment to map which solutions fit which problems. What has to be avoided at closing is the client fitting the price to the problem, always drifting toward whatever feels cheap and gets the job done. It is good practice to hold a price floor below which we do not work. Ideally those situations never arise, and when they do, it usually means qualification failed at the first step.

Social proof as a qualification asset. Qualification also runs across account criteria: which companies we have worked with before, whose testimonials we can use for exposure, and which case studies show how we work. Sharing those is useful for establishing credibility. It gives prospects a sense of safety, evidence that we hold the pedigree and expertise to get the job done.

Messaging and outreach. With a strong prospect list, messaging comes next. Most outreach should be warm, and where cold outbound is used it has to be informed, anchored in what the prospect is working on right now and what is most current for them. Offer multiple CTAs, give them space, and make it easy to say no, because we do not want to waste our time or theirs, especially with a well-established brand behind us. Done that way, most messaging performs well.

Operating cadence and sales ops. From there it is process again: reliable follow-up cadences that work leads through the funnel, systems that sync well with the delivery teams, and a shared calendar where our engineers can see audit timelines and team assignments directly. Setting up sales ops is not easy. It is extremely time-consuming, and we must not cut corners where rigor matters. We will need internal policies on data submission, and what we build should run through the lens of trimming requirements wherever possible. Processes exist to propel us toward goals, not to hold us back.

14Why Process Discipline Matters

Repeatability is what makes these processes valuable. They demand upfront work, and the more work goes in, the more effectively you can analyze and execute against them. A system is only as good as the person using it. You can run the best organized, highly featured, well-integrated CRM in the industry, but if nobody feeds it data, it'll produce nothing.

Across most firms there is no operational excellence like this. I've seen data pile up without labeling, and companies and contacts get created that are never used again. Meanwhile procurement at large organizations is even more complex than people assume. If we are not keeping proper logs on every account, following up regularly, and making clean transitions when someone is onboarded or offboarded so the next person can pick up the conversation, we are bleeding value.

Part VPositioning and Marketing

15Reference Rights and Data Governance

We need clarity on contract terms. Which clients grant us reference and case study rights, where is logo usage permitted, and which NDAs constrain what we can show prospects. Similar review applies to user data generated inside the product and what we are permitted to do with it.

16Positioning

This goes broader than it first appears.

The job is to let quiet strength speak in the register of competence and excellence, and that is exactly how the content engine should run: publishing bug writeups, technical material, and infrastructure work. Having a track record like that fuels the reputation of a new product, because if you have done the work before, you can sell it.

Security-oriented teams can see straight through marketing fluff and industry jargon, and they respond to partners who make their thinking, their methods, and where possible their pricing legible rather than hiding everything behind a contact-sales form.

Our industry is moving from promise-based to evidence-based security, where customers expect proof rather than assurances, and public bug writeups, research, and infrastructure contributions are exactly the kind of evidence we need.

The most valuable growth in this market comes from word of mouth, and word of mouth cannot be bought. It comes from doing the work well and letting teams carry the story into their networks. A well-known constraint to plan around is that security clients are sometimes reluctant to publicly disclose who audits them, so reference customers and public testimonials are harder to secure here than in other industries.

That is why nailing down reference rights, case study permissions, and named logos (covered above) is a direct input to how much social proof we can actually put to work.

17Marketing and Content Engine

What the firm already publishes matters most: bug writeups and how findings are presented. We have a process that needs dedicated input from our engineers, with an editor making the concepts accessible, plus someone fact-checking that what is published matches what actually happened, because losing reader trust is not a risk worth taking.

The process can be as follows:

Syncing calendars inside HubSpot makes sense, or whatever tooling is already standard within the org. Multimedia is working in this market, so if there is appetite among team members, launching a podcast where we talk freely and in depth about the work is worth doing, with the caveat that it takes real time, so consider doing guest podcasts first.

Throughout all of this the focus stays on outputs, because over-engineering process cripples speed, and speed to market is as relevant as ever.