What Cyber for Builders asks of a security company

Ross Haleliuk's Cyber for Builders: The Essential Guide to Building a Cybersecurity Startup (Venture in Security Press, 2024) is written for founders, product leaders and investors. It is not a book about attack techniques or architectures. It is about why some security companies become durable businesses while most stall, and its answer is uncomfortable for anyone who likes building things: the technology is rarely what decides it.

This post summarizes the book's thesis in our own words, section by section, and then turns it on ourselves. The quotations are short and attributed; the book is worth reading in full.

The thesis in one paragraph

Security is a market where buyers cannot easily verify what they are buying, where trust is earned slowly and locally, and where most money moves through partners rather than directly from vendor to customer. In that market, a startup wins by solving one painful, validated problem for a clearly defined buyer, proving it with evidence rather than promises, and reaching that buyer through the channels they already trust. Breadth, dashboards and vision come later, if they come at all. The book's closing advice is to stop following inherited playbooks on autopilot and reason from the specific problem and the specific buyer.

Section 1: security is a different kind of industry

The book opens by explaining why security does not behave like other software markets.

Buyers cannot easily tell what works. A security product is judged by attacks that did not happen, which makes outcomes hard to measure and marketing claims hard to falsify. Buyers fall back on reputation, references and peers.

Trust is local. Haleliuk puts it plainly: "While cybersecurity innovation is global, trust isn't." He notes that an American company will prefer a US provider and a French company will buy from French startups. Adoption follows trust, and trust follows proximity, regulation and shared context.

No one wins the whole market. Because adoption is slow and trust-based, the largest vendors each hold under 10% of the total market, even when they lead individual segments. There is room for many companies, but each has to earn its place segment by segment.

Section 2: the ecosystem around the buyer

The second section maps everyone who stands between a vendor and a customer: resellers, distributors, managed service providers, consultancies, cloud marketplaces, insurers, analysts and investors.

The headline figure is that over $9 of every$10 of enterprise security spend flows through the channel. A startup that plans to sell only directly is planning to compete for the smallest part of the market. Partners, however, do not create demand; they amplify demand a vendor has already proven. They engage once a product has closed deals, has a clear package and leaves room for the partner's margin and services.

The section also covers how buyers really work. The CISO is one stakeholder among many. Practitioners, procurement, compliance, IT and the board all have a say, and a vendor needs to map that journey rather than assume a single decision maker.

Section 3: the trends reshaping the industry

The third section describes forces Haleliuk expects to define the next decade.

From promise-based to evidence-based security. Buyers increasingly want to see how a product works, test it against their own environment and write their own logic, instead of trusting a black box. Transparency, open detection content and shared vocabularies such as MITRE ATT&CK are part of this shift.

Data gravity. As organizations move security data into large data platforms, tools increasingly come to the data rather than pulling the data into yet another silo. Vendors that build on the customer's data layer gain a distribution advantage; vendors that demand their own copy pay for it.

Products and services are blurring. Many organizations do not have the people to operate sophisticated tools. Companies that wrap software with a thin layer of expert service, delivering an outcome rather than a console, are growing fast.

Openness and interoperability. Open source, open standards and portable data reduce buyer risk and make it easier to adopt a small vendor.

Section 4: a founder's guide

The longest section is practical.

Validate the problem before building. The book recommends dozens of discovery interviews, roughly 40 to 50, conducted to listen rather than pitch, and points readers to Rob Fitzpatrick's The Mom Test.

Build painkillers, not vitamins. Vitamins are pleasant and are the first budget line cut. Painkillers solve a hard problem someone is accountable for.

Do not design for the top 1 to 5%. Founders who come from the most advanced security teams tend to build for buyers like their former employers. Most of the market is less mature, has fewer people and needs products that deliver value without an expert operator.

Pick an ideal customer and stay with it. A narrow initial customer profile, a small set of power users and a clear buyer journey beat a broad addressable market on a slide.

Know your unit economics. Margins, sales cycles and the cost of serving each customer decide whether growth helps or hurts.

Expect consolidation. Today's products are tomorrow's features. A startup needs a reason to exist that a platform vendor cannot absorb in a release or two.

Go-to-market has more routes than direct sales. The book lists channel partners, data platforms, virtual CISOs, cyber insurers, product-led growth and adjacent vendors, with practical advice on each.

Section 5: how to fail

Section 5 is a catalogue of failure modes, and it is the section most founders should reread. Among them:

• Confusing a product with a company. A good product without distribution, pricing and support is not a business.
• Unrealistic distribution plans. Assuming buyers will find you, or that partners will sell an unproven product.
• Scaling before product-market fit.
• Team composition. When customer acquisition gets hard, Haleliuk writes, "the all-engineering founders retreat to the area they can control: the code." More features replace the selling and discovery the company needs. He favours founding teams that combine technical and commercial skills.
• Becoming another "single pane of glass". He quotes a friend: "Most security products want to become a single pane of glass but instead they become a single glass of pain."
• Features in search of a product, and poor timing.
• Outsourcing go-to-market before the founders understand how their own product sells.
• Selling to customers the way you sell to investors. An investor buys a vision, with perhaps 10% of it built. An enterprise buyer needs about 90% of what it is buying to exist today.

Section 6: build what the world needs

The book closes by asking founders not to build "on autopilot". Instead of copying the standard path of stealth mode, venture rounds and a long build before talking to customers, Haleliuk suggests evangelizing the problem early, raising modestly from angels, signing design partners and selling before the product is finished. The rule is first-principles thinking about the specific problem and the specific buyer, not a playbook that worked a decade ago somewhere else.

What the book asks of Samyoga

We read the book as a checklist and scored ourselves against it honestly. Some of it reads as confirmation; more of it reads as a work list.

Trust is local, and we build for that. Samyoga is built for Indian enterprises that need their security data to stay under their own control. It runs on the customer's infrastructure, including air-gapped networks, and maps to Indian regulation such as CERT-In directions and the DPDP Act. The book's observation that trust follows national and regulatory boundaries is the premise of the company.

Evidence over promises. Our detections are written in plain English and compiled into readable SQL that an analyst can inspect, run and change. Telemetry is normalized to the open OCSF schema and detection content can come in as Sigma rules. A customer should be able to see why something fired, not take it on faith.

Data gravity and openness. Customer data stays in a store the customer owns, in an open schema they can query directly.

Products and services. Many of the organizations we meet do not have a security operations team large enough to run another console. The book's point about outcome-based services matches what we hear: the product needs a human operating layer, whether from us or a partner.

The harder chapters are the ones about focus and distribution.

Focus. We have built across SIEM, exposure analysis, identity graphs and compliance. The book's warnings about the single glass of pain and features in search of a product apply to us. Our answer is to lead with one problem for one buyer: a sovereign, evidence-based SIEM for regulated Indian enterprises, especially teams moving off platforms whose ownership or deployment model no longer fits them. Everything else has to earn its place by serving that buyer.

Distribution. If over $9 of every$10 flows through partners, a security company in India needs partners who can deploy, operate and support it. Partners need proof first: referenceable customers, a simple package and a role in delivery that pays them. Building that proof is our job, not theirs.

Selling what exists. The 90/10 rule is a useful discipline for any writing about a product, including this blog. We try to state what Samyoga does today, and to label direction as direction.

The book's last point may be the most useful one. Playbooks written for the US enterprise market do not transfer unchanged to Indian banks, insurers, pharmaceutical manufacturers and hotels. Haleliuk's advice to reason from first principles about the problem and the buyer is the part we intend to follow most closely.

Cyber for Builders: The Essential Guide to Building a Cybersecurity Startup by Ross Haleliuk, Venture in Security Press, 2024. ISBN 978-1-7382341-1-0.