4.2: Build vs. Buy

Build vs. Buy

You lead engineers. When a security need surfaces, someone on your team will say “we could build that in a sprint.” They’re usually right about the sprint and wrong about everything after it.

The mistake is in the denominator

Engineers estimate build cost as construction cost. The real cost of a built security tool is construction plus operation, forever: the on-call rotation it joins, the upgrades when its dependencies go end-of-life, the tuning when your environment changes, and the bus factor when its author leaves. For security tooling specifically, add one more line item most build-vs-buy math omits: a security tool that silently stops working doesn’t page anyone. A homegrown log pipeline that quietly drops events isn’t a degraded feature — it’s a blind spot you’ll discover during an incident, which is the most expensive possible time.

The classic case is the self-hosted SIEM. An open-source ELK stack costs nothing to license and a weekend to stand up. Eighteen months later it is a half-FTE of care: index management, storage growth, parser breakage every time a vendor changes a log format, and detection rules nobody has reviewed since the engineer who wrote them changed teams. The subscription you avoided was real money. So is half an engineer, and engineers are more expensive.

Where the math actually lands

A usable frame for a technical leader:

Buy when the capability is undifferentiated — when your version would look like everyone else’s. EDR, email security, SSO, vulnerability scanning, awareness tooling, log storage. There is no version of your company that wins because it wrote a better antivirus. Vendors amortize their engineering across thousands of customers; you amortize yours across one.

Build when the capability is entangled with what makes your product yours. Authorization logic inside your application. Anomaly detection that only makes sense on top of your data model. Glue between systems no vendor pair integrates. Here vendors are generic by definition, and the integration work is most of the work anyway.

The trap in the middle is the capability that feels differentiated but isn’t — “our environment is special, so we need custom alerting.” Every company believes its environment is special. Almost every alerting need is a config file in a product that already exists.

The inversion

The lesson’s title says the math inverts at scale, and it does — in both directions. At 40 people, buy almost everything: your scarce resource is engineering attention, and every internal tool is a tax on it. At 4,000 people, some build decisions start to win: vendor per-seat pricing scales linearly while build cost doesn’t, and you can afford a platform team whose actual job is operating internal tooling. The mistake is borrowing the big company’s answer while you have the small company’s headcount. If nobody’s calendar has “operate this tool” on it, you can’t afford to build it — regardless of what the sprint estimate says.

One number for the CFO

When you do want to buy and need the case, don’t argue “best practice.” Argue the operating math, which Module 3 taught you to put in business terms: “Building this is three engineer-weeks up front and roughly a quarter of an engineer forever. The vendor is $30K a year. A quarter of an engineer costs us more than $30K, and the engineer is better spent on the product.” CFOs recognize make-vs-buy — it’s a decision finance departments have frameworks for. Use their frame and the conversation gets short.

And when the answer is buy, the next three lessons are about not getting snowed on which vendor — because “buy” doesn’t mean “buy whatever demos best.”