IKEA effect in cybersecurity or why we love the things we build
How the IKEA effect shapes the success, failure, and adoption of cybersecurity products
Security professionals take a lot of pride in the things they build - playbooks, detections, automations, open source tools, and more. Sharing these isn’t just about showing off; it’s about contributing to the craft, earning peer respect, and pushing the industry forward. What’s not being discussed is the psychology of these behaviors, the “why” behind our love for tooling, and the phenomenon that explains a lot of that - the IKEA effect. In this issue of Venture in Security, I am discussing the IKEA effect, what it is, how it works, how it shapes the success, failure, and adoption of cybersecurity products, and what security leaders should know to navigate it.
This issue is brought to you by… Tines.
Automate 95% faster with a low-code platform
More security teams are moving away from custom scripts like Python, PowerShell, and Bash in favor of low-code platforms. Why?
This new guide, Tines vs Python: Understanding alternative approaches to automation, breaks it down.
Inside, you'll find:
A side-by-side comparison of Tines vs Python across HTTP requests, webhooks, data manipulation, and more
A real-world case study automating a Slack news feed for threat intel, built in both Tines and Python
Discover why companies like Jamf go no-code for 95% faster workflow build time, stronger security, and fewer errors.
A quick note for transparency: while we do accept sponsorships, we never publish sponsored content. Sponsors pay for ad placement that appears alongside the article or newsletter, but they have zero influence on the content itself, and in fact, they don’t even know which piece they’ll be sponsoring in advance. This model has worked well over the years to eliminate bias. That said, by coincidence, this week’s topic happens to somewhat overlap with the space in which the sponsoring vendor operates. I want to be clear that this is purely incidental and this vendor had no impact on the content of the article (as you’ll see for yourself as you read).
IKEA effect and psychology of security tools
The IKEA effect is a psychological bias where people place a disproportionately high value on products they helped to create themselves compared to those that come pre-assembled. It helps explain why a poorly assembled bookshelf often feels more meaningful than an amazing piece of furniture from a high-end store: it’s not about perfection, or even quality, but about participation. Since a person invests time and effort into bringing something to completion, in their eyes the result becomes much more valuable. The IKEA effect is so poverful, that a study in 2011 found that people were willing to pay 63% more for furniture they had assembled themselves than for equivalent pre-assembled items.
The IKEA effect can be found outside of IKEA. For example it’s a huge part of why people love LEGO and Build-A-Bear Workshop, and it is also why we feel like a sweater we spent time knitting is worth more than the same one from H&M (even though objectively, it is not). There are so many areas of life impacted by the IKEA effect that I would greatly recommend reading about it more. I am going to assume some basic understanding of this topic, and instead focus on discussing how this phenomenon looks like in our industry.
In cybersecurity, the IKEA effect is particularly strong. Security professionals work with products that demand customization and tuning. The tools they use often require significant configuration before they start working, and this effort not only increases switching costs, but also creates a sense of accomplishment and a perception of high emotional investment. Whether it’s writing detection rules in a SIEM, defining policies in a firewall, or building automated workflows in a SOAR platform, the act of creation leads to the feeling of ownership.
Why security work invites the IKEA effect
The fact that the IKEA effect is very strong in security is not a coincidence but a direct result of how security works. Let me explain.
Security is inherently bespoke and environment-specific
Every organization is different, with different crown jewels, different technology stacks, and different needs. Since no two environments are the same, off-the-shelf tools rarely work without tuning. Which configuration is “right” is highly contextual and dependent on a myriad of factors. Cloud configurations vary based on provider, region, and architecture decisions, and each cloud provider comes with different APIs, IAM models, and visibility gaps. Some organizations still have a large number of legacy applications while others are purely SaaS. Some emphasize least privilege and rely on identity for access, while others heavily use perimeter-based controls and implement security on the network (you can’t add an agent on every OT device or get rid of the network on the factory floor). Regulatory diversity (HIPAA, PCI, GDPR, DORA, etc.) add yet another layer of variation.
Because of all this variability, it’s widenly understood that all SIEM, DLP, ITDR and other detection tools, all firewall rules, and any other types of configurations have to be adapted to the individual environments.
Every company’s risk appetite is different
Every company’s risk appetite is dependent on its industry, culture, technology stack, and criticality of different aspects of the system. For example, a failed conveyor belt at a factory may mean deferred revenue (some parts may be delayed but will likely still make it to the buyer), but a failed payment processing system may mean a revenue loss (buyers won’t come back next day to retry a failed payment method on an ecommerce site). These differences make it almost impossible to build a one-size-fits-all solution. Instead, in security there is a natural demand for tools that can be shaped, extended, or reassembled to fit each organization’s evolving threat landscape, business requirements, team structure, and risk appetite. Unlike IT infrastructure or developer tools, where consistency and repeatability are often the goal, security platforms succeed or fail based on how well they accommodate this diversity. A rigid, opinionated solution may offer initial value, but it quickly becomes a liability if it can't adapt. In security, flexibility is not just a feature, it’s a survival trait (this is especially true for products targeting large enterprises).
Security engineers have a deeply ingrained builder mindset
Although it is true that a lot of security work is pretty mundane, similar to any other job, there is a lot of creativity that goes into being a security engineer or a security analyst. Their work is about crafting logic, be it detection logic, policy logic, or access logic. Analysts write custom Sigma rules, create complex correlation queries, design layered firewall policies, and build automation playbooks. Each rule and response is a reflection of how their team understands threats and how they choose to respond (now, most companies never get that far but that’s a different topic altogether). Security engineers and architects often build scripts, automation playbooks, and even large, complex platforms tailored to their organization’s needs in-house. Canva, for example, built a tool for endpoint vulnerability management, Discord developed a solution for authorization, and Rippling went as far as to build their own SIEM. There are plenty of examples where the next generation of security solutions originated inside of large companies, as is the case for Panther (Jack built StreamAlert) or Northpole Security, the founders of which built Santa during their time at Google.
I am not here to talk about build vs. buy decisions, or to discuss if security teams should be building stuff themselves (for that, I have other articles). What matters is that cybersecurity analysts and security engineers have a deeply ingrained builder mindset, and the things they do at work are creative, iterative, and often personal. The things they do lead to deeply personal sense of creation and authorship, and these are precisely the feelings that feed the IKEA effect.
IKEA effect for security vendors
Examples of IKEA effect in action
There are plenty of examples of IKEA effect but nothing illustrates it as well as the security orchestration, automation, and response (SOAR) platforms. Unlike other tools that ship with pre-configured features, SOAR solutions are essentially automation kits security professionals can use to build something tailored to their organizations. From Demisto and Phantom, to Tines, Torq, Swimlane, BlinkOps, and Tracecat, to name a few, security automation platforms since their very beginning have seen a lot of love in the community. A big part of that is surely, due to the fact that they reduce the amount of manual work security teams need to deal with, but I’d argue that the IKEA effect has also played a critical role.
With security automation tools, teams invest months and years building playbooks, developing logic trees, tuning conditions, and debugging integrations (they even spend their free time building tools on these platforms!). Each piece of automation reflects internal processes, team preferences, and evolving threat models, and the end result isn’t just an automation engine, it’s a handcrafted artifact that gives someone on the team a strong sense of pride. This effort pays dividends in terms of ownership and loyalty. Security teams grow attached to the workflows they build, and the platform becomes difficult to replace. Even if better tools emerge, the emotional and practical sunk cost of switching is often too high. This creates high retention for vendors, but also creates the risk of locking security organizations into systems that no longer scale or serve them well.
The IKEA effect in security goes far beyond SOAR platforms, or their newer agentic equivalents. Splunk is a textbook example of a product that thrives because of the IKEA effect. Splunk’s real power comes when users write their own detection rules (or at least adjust the existing ones to their needs), design dashboards, and architect complex search queries tailored to their environment. Over time, security teams invest deeply in crafting logic that reflects their threat models, business context, and data sources. This customization creates a sense of ownership that makes Splunk feel indispensable, even if alternatives are cheaper, faster, or simpler. The more a team builds inside Splunk, the harder it becomes to leave, not just because of technical dependencies and data gravity effect, but because the people using it are so deeply embedded into Splunk ecosystem.
When to lean in into IKEA effect and when to hide the effort
Startup founders and cybersecurity product managers can use the IKEA effect to their advantage, but only if they know when to amplify it and when to abstract it away. For technical audiences, providing modular frameworks and visual editors (e.g., low-code policy builders) gives users the satisfying feeling of construction without overwhelming them with complexity. Security automation platforms with drag-and-drop experience really lean into this idea with visual workflows that combine power and simplicity.
At the same time, not every user wants to build from scratch and not every product should be built from scratch. Most of the security products are bought because they have a perspective and because they are designed to abstract away the complexity security teams don’t have the time or resources to handle. For example, companies rely on endpoint security vendors to do the heavy lifting around threat research and detection engineering to protect them from threats on the endpoint; they rely on email security vendors to provide intelligence and detection logic for email, and so on. In detection engineering or cloud posture, turnkey value is often more important than configurability. Here, smart defaults, ML-powered suggestions, and curated content libraries can remove friction (posture management tools have been good examples of this in action).
The key is to balance both modes: give users the option to shape the system when needed, but don’t require them to. Let those who want opt into complexity but don’t require everyone to go deep into complexity in order for them to get value from the product. For example, provide comprehensive coverage but make it easy to adjust and tune detection logic. Offer customization, but also offer instant value and out-of-the-box solutions. By embracing the needs of different customer groups, vendors can appeal to both the builders and those looking for “set it and forget it" solutions.
Designing products that leverage IKEA effect
Understanding the IKEA effect has major implications for how security vendors design products and go to market.
First, it helps explain why products that are "too easy" often struggle in security. Simplicity in this market can be mistaken for lack of depth similar to how low cost is often seen as lack of quality (I’ve heard stories where companies would pass on a cheaper CSPM because they’d assume that it’s not as good simply bacause it’s cheaper). Customer segmentation also matters: security buyers at large enterprises want tools that feel robust, configurable, and extensible, even if they don’t use all those features immediately, while those in mid-market want the ability to pick modules they need and to only use those.
Second, the IKEA effect reframes the product positioning discussion. Instead of selling a black box that does everything, vendors may succeed more by offering a highly configurable solution, or a set of lego blocks users can build with. Even if only a subset of users customize deeply, the perception of control and flexibility can drive adoption. In security, buyers are often overly optimistic about what they’ll be able to do, and vendors who support that optimism tend to do better than those that directly say “You’ll never use that”. All that said, im’s critical that products can come pre-configured as much as possible so that security teams are not required to do the heavy lifting.
Finally, vendors can simulate effort through community-driven assets. Pre-built playbooks, reusable queries, and shared policies can make users feel like co-builders. GitHub-style sharing or marketplace integrations allow users to discover and remix components, boosting perceived ownership without requiring teams to build from scratch. This is why security information and event management (SIEM) vendors like Splunk provide open source detection packs, and it’s also why security automation platforms offer libraries of pre-built playbooks that can be customized and adapted to different environments
IKEA effect for security buyers
Balancing pride and practicality
Security buyers are not immune to the IKEA effect, and while vendors must do what they can to drive adoption of their solutions (such is the nature of being a vendor), CISOs must be smart about what they are using, how, and why. When a security tool demands significant setup, tuning, or integration work, buyers often feel a sense of accomplishment and pride in having navigated the complexity. That pride can quickly become entangled with the product’s perceived value. A platform that took six months to roll out, integrate with dozens of systems, and train staff to use becomes a symbol of the team’s capabilities and hard-won progress. This emotional attachment can make it difficult to objectively assess whether the tool is still the right fit.
This sense of achievement and pride can cloud judgment. Just because a team invested time and effort to implement a tool doesn’t mean the tool continues to deliver proportional value, and just because a solution might have made sense a year ago, doesn’t mean it does now. Some buyers fall into the trap of justifying continued investment in underperforming platforms because of the effort they already spent, not because of the outcomes the solution is helping them to achieve. This classic sunk cost bias shows up when a SOAR platform is kept alive because of “how much work we’ve put into it,” or when a homegrown detection pipeline remains in place despite the fact that off the shelf solutions caught up and are now 10x better.
Smart buyers must balance pride with practicality. It’s not about discarding the past, it’s about regularly re-evaluating tools through the lens of current and future needs, not past investment. Pride in building something meaningful should be celebrated, but it should not prevent a transition to better solutions when circumstances change. Mature security leaders embrace tools they’ve customized, but remain pragmatic about evolving, and the most mature are those who can both celebrate the work their teams have done and know when to move on.
Dealing with the illusion of differentiation
One of the most subtle consequences of the IKEA effect for security buyers is the illusion that their implementation is uniquely valuable simply because it’s custom-built. After months of tuning rules, building workflows, or designing dashboards, it’s easy for teams to believe their setup is special and optimized in ways no off-the-shelf competitor could match. In practice, many of these customizations replicate similar logic seen across industries: a phishing playbook that mirrors industry templates, a detection rule that matches known Sigma patterns, or a dashboard layout that resembles a best practice suggested by another vendor.
This illusion of differentiation can lead CISOs to overestimate the uniqueness of their environment and reject newer, more opinionated tools that could deliver faster time-to-value. When vendors offer turnkey solutions or managed content, buyers may resist with responses like “we already have that covered,” when in reality, what they have may be outdated, brittle, or inconsistently applied. The emotional investment in the homegrown solution can distort their assessment of whether a new option is genuinely better.
To combat this, security leaders need to distinguish between real differentiation and unnecessary reinvention. Customization should solve a unique business problem, not fulfill a need for control or novelty. Buyers should ask: is this thing we built ourselves really better than what’s available now in the market, or do we just feel that way because we built it? Being able to recognize where commoditization is an advantage, not a weakness, and where undifferentiated heavy lifting is unnecessary, is a sign of a high-functioning, outcome-driven security organization.
Designing for stakeholder validation
The IKEA effect doesn’t just influence internal decision-making, it also affects how security buyers present their work to external stakeholders like the board, executive leadership, and even their peers. A platform that requires complex configuration and hands-on effort becomes easier to defend in slide decks and strategy reviews, easier to add as an accomplishment on their resume, and quite exciting to give a talk about at an industry event. CISOs can point to months of engineering effort, complex requirements, team-led customization, and the sophistication of their workflows to demonstrate maturity and intentionality. The act of building becomes a proxy for demonstrating thoughtfullness, even if the outcomes lag behind.
This dynamic can lead to subtle but significant misalignment. Boards and executives care about measurable outcomes: reduced risk, faster response times, better compliance. Security leaders, on the other hand, impacted by the IKEA effect, may emphasize effort and complexity instead of simplicity and effectiveness. A platform that works out of the box but requires minimal customization may be perceived as “less strategic,” even if it delivers stronger results than an alternative built in-house, just because it doesn’t offer the same storytelling potential.
To avoid this pitfall, CISOs have to remember to anchor validation around outcomes rather than effort. One example is showing how the investment in customization led to faster time-to-detect, measurable coverage expansion, or fewer false positives, and not just that “a lot of work went into it.” The best validation for security buyers isn’t that they built something complex, it’s that they did something that works, and that is right for their organization (which may mean buying an existing platform, or even becoming a design partner for a startup instead of building a solution in-house). I used to think that Bay Area security teams are the only ones that fall into the trap of building stuff that was already built by tens of vendors (security engineers want promotions, and this is often one way to achieve that), but I have now seen that this problem is universal, and that many companies continue to reinvent the wheel when trying to solve just any problem.
Image Source: ChatGPT