Build vs Buy: should an SME build its own security stack?

Sooner or later every technical lead faces the same question. There is a security need to cover - a SIEM, an EDR, some threat intelligence, a deception system - and two roads: buy a product, or assemble it from open source components. Vendors have a ready answer ("buy ours"); open source purists have another ("build everything"). Both are wrong, because the right answer is "it depends" - and the deciding factor is almost never the one everyone fixates on: the license price.

The cost you see and the cost you don't

The license is the visible cost, and it is also the only one that usually makes it into the comparison. But the real cost of a security system is not what you pay for it: it is what it costs you to own it over time. Buying shifts the cost from your time to your wallet: you pay, and someone else handles updates, integrations, product security, midnight support. Building does the opposite: you zero out the license and pay in time, maintenance and risk. Time-to-value, the learning curve, the bridge that breaks on the first update, the single person who knows how it all works: these are real costs, they just don't come with an invoice. Comparing list prices means comparing the wrong part.

When buying is the right call

Buying wins more often than an engineer likes to admit. It makes sense when the capability is a commodity: email protection, EDR baseline, device management are problems already solved, and solved well, by mature products - rebuilding them from scratch is donating your time to something someone else has already closed. It makes sense when compliance requires a certified product, and a homemade solution, however good, doesn't carry the stamp the auditor wants to see. It makes sense when you have no in-house engineering - or no continuity to maintain it over time. And it makes sense when time-to-value matters more than control: if you need detection tomorrow, not in three months, buying is the honest answer.

When building (or assembling) makes sense

Building wins when the market doesn't fit you. Every lead who has worked long enough knows that moment: the integration that doesn't exist, the workflow that won't bend, the enterprise price that, for an SME, kills the project before it even starts. That is where "buy" stops making sense. Building makes sense when you have the engineering and want to own the problem instead of opening a ticket and waiting; when the capability is a differentiator and not a commodity; when vendor lock-in is a real strategic risk; and - the most common and underrated case - when the real value is not a single tool but gluing different tools together.

The third way: assemble, don't reinvent

Here is the point the "build vs buy" dichotomy hides: the best security stacks are neither fully bought nor written from scratch. They are mature open source components, wired together with your own integration code. You don't write a SIEM - you take a proven SIEM and connect it to a proven SOAR. The engineering work, and the value, is in the glue, not the bricks.

That is exactly how I built the platforms I work with every day. Presidio, the XDR platform, does not contain a single line of SIEM written by me: it is Wazuh for detection, Velociraptor for EDR, Shuffle for orchestration, DFIR-IRIS for cases, MISP for threat intelligence - six solid open source systems, held together by bridges I wrote. That is where the "build" lives: not in reinventing components that already exist and work, but in making them talk in a way no turnkey product offered at a price an SME can sustain. You own the integration, not the infrastructure.

The honest price of owning the code

That said, anyone selling you "build everything" as an always-winning choice is hiding half the bill. When you build or assemble, you own it at 3 AM. There is no vendor to call when a bridge breaks in production: there is your source, and there is you. There is the bus factor: if the person who built it all leaves, who maintains it? There are the updates that break integrations, the security of your own glue, the technical debt that grows silently. The rule I carry with me is simple: don't build what you can't maintain. Building is a choice you pay for over years, not just on deploy day.

A checklist to decide

• Commodity or differentiator? If it is a solved, standard problem, buy. If it is what makes you different, consider building.
• Do you have the engineering - and the continuity? Knowing how to build it today isn't enough: you need someone to maintain it when the builder is gone.
• What is the 3-year TCO? Add license and time, maintenance, on-call. Compare totals, not list prices.
• Does the product really fit, or are you forcing it? Bending the company to the tool is a huge hidden cost.
• Does compliance require a certificate? If so, a homemade solution may not be enough regardless of quality.
• Is lock-in a strategic risk? If being held hostage by a vendor scares you, open source assembly gives you leverage back.

The lesson

"Build vs buy" is the wrong question. The right one is: where do you want to spend - money, or time and responsibility? For an SME the balance point is almost always the same: buy what is commodity, assemble and own the glue for what is strategic, and build because it is the only way to make things fit - never because building feels good. The software that protects your company doesn't need to be the most elegant: it needs to be the one you will still be able to run three years from now.