A Time to Build, a Time to Buy - How to Make a Choice

Every security leader knows the allure of building tools in-house. When you build, you control every detail: the data stays inside your walls, the features fit your workflows, and you don’t depend on some vendor’s roadmap. It’s empowering.

And I should know! As a security leader, I’ve found myself at the crossroads of building versus buying too many times to count. In my role at Material, I’ve talked to scores of security leaders about their own experiences navigating this decision, and certain themes have cropped up time and again.

The fact is, most security teams will use some combination of building and buying at different times and in different scenarios, but the key to unlocking efficiency is in identifying when to take each approach and understanding the tradeoffs.

The Build → Buy → Build Cycle

Security, like the tech industry at large, moves in cycles.

• First, pioneers (like Google, Facebook and Dropbox) build because their needs are not served by the market.
• Then, those veterans buy, as the market catches up with their needs.
• Eventually, security needs evolve and vendors no longer offer an optimal solution which leads teams to build again.

Each turn of the cycle starts at a higher level. The market’s current “buy” phase offers more flexibility, transparency, and security than ever before.

Why Building Can Be the Right Move

At the highest level, building makes sense when the problem is deeply tied to your company’s unique environment or when trust is on the line.

Trust and Access Control

If a vendor product demands privileged access to your production systems or sensitive data and you’re not comfortable granting it, building internally can be the only acceptable option. No amount of convenience beats control. For example, if the only tool available requires access to your production environment and doesn't offer fine-grained access policies, then it might be better for you to build something internally with the right-sized access controls.

When the Market Hasn’t Caught Up

Some challenges are just too new to have a commercially available solution. When companies like Google and Facebook first started scaling their infrastructure, there were few to no services that could handle their scale. They had to build. Over time, as more companies reached cloud scale, tools that could handle this scale emerged and building for the same use cases made less and less sense. If you’re trying to solve a problem that is such a new concept that the market hasn’t caught up with, you may find yourself needing to build.

Unique Environments, Unique Logic

A company running an unconventional infrastructure, or one that requires custom logic layered on top of a platform like AWS or Google Workspace, may find no commercial solution fits. Building allows for exact alignment with internal systems. 

These are the top three legitimate reasons to build, and they all boil down to the same thing: When it’s no longer “build or buy,” but “build or do nothing,” then the choice becomes crystal clear. 

But the story usually turns where the ability to create something tailor-made feels seductive and, for a certain kind of engineer, irresistible.

The Harsh Reality: Why Buying Wins More Often

The argument for building often ignores the most expensive resource in any organization: people.

Building is not a project. The need to maintain and improve self-built tools is evergreen. Security teams have to adopt a product mindset to be successful which means thinking about UX, bug fixing, infrastructure maintenance, redundancy, resilience, and application security. It also can mean adding more on-call rotations in case the service goes down and building your own resources to train new employees when they join the team. Few security teams have the time, headcount, or product experience to build and maintain quality tooling. And that’s where too much building becomes a trap.

The Cost of Human Capital

Two engineers can spend a year building a “good enough” internal tool before factoring in ongoing maintenance. I’ve seen the initial investment in building a tool cost somewhere between $350,000 to over half a million dollars, with up to $300,000 to maintain, every year after that. And that’s before factoring in the time needed to accomplish day-to-day tasks within the tool. A commercial product managed by one person (or a fraction of a person’s time) often outperforms that, at a cost more in the $50,000 to $150,000 range annually.

Maintenance Never Ends

The first version is only the beginning. Someone has to patch, scale, update APIs, and fix bugs as the company evolves. When the original builder leaves, the tool often decays into what one security leader called “the sh*t sandwich:” legacy tech debt disguised as innovation.

Hiring and Retention Pain

It’s easier to hire engineers who know standard industry tools than to train them on your homegrown system. Building narrows your talent pool and reduces long-term flexibility.

The Project vs. Product Trap

Most internal builds are treated as projects that come with a corresponding endpoint. But software development never ends. Vendors live in a product mindset because their survival depends on it. Security teams don’t.

What Vendors Do Better

Simply put: modern security vendors have the advantage of scale and focus. 

Even a small vendor with a dedicated team of six to ten engineers refining a threat modeling tool will outpace a lone in-house developer every time. They learn from hundreds of customers, ship improvements faster, and maintain integrations across ever-changing ecosystems.

Buying also provides flexibility. If a product stagnates, you can switch. If the market evolves, you can adapt. When you build, you’re stuck maintaining yesterday’s ideas.

The Real Work: Connecting, Not Rebuilding

The most impactful security teams today don’t spend their cycles reinventing commodity tools. They spend them stitching great tools together.

They automate with APIs and LLMs, integrate systems to make findings more actionable, and focus on reducing dwell time and hardening identity controls. That’s the work that moves the needle; not maintaining a homegrown ticketing pipeline or endpoint agent.

Conclusion: Build When You Must, Buy When You Can

Building feels like control. Buying feels like compromise. But in reality, buying often means freedom: freedom to focus on the work that truly matters, and to deploy your people where they add the most value.

Security teams should only build when trust demands it, when the market hasn’t caught up yet, or when the problem is uniquely theirs.

Everything else? Buy it, integrate it, and move on to the next high-value problem. Because the real risk isn’t trusting a vendor. It’s wasting brilliant engineers on non-unique work.