Stop asking if you can build. Start asking if you should.
“Build vs Buy” is the oldest debate in engineering. But in Identity Security, getting it wrong doesn’t just waste money. It breaks trust.
Buy a vendor solution and you get speed, compliance checkboxes, and someone to blame when things break. But you’re also betting your roadmap on their priorities. When they go down, you go down. When they raise prices, you pay up.
Build your own and you get total control. You own your destiny. You also own every bug, every 3 AM outage, and every vulnerability that keeps your security team up at night.
So how do you choose?
Most teams frame this as “engineer ego” vs “vendor lock-in.” That’s the wrong lens. The real question is: Are you building a utility or a competitive advantage?
Most teams get this wrong because they skip that question entirely. They decide based on what feels safe, what the exec team expects, or what the vendor promised in the last demo.
Here’s the framework I use to strip away the politics and find the right answer.
The Framework
Teams typically do extensive evaluations: vendor demos, POCs, TCO analysis, feature comparisons. The process is rigorous. Yet many of these decisions still end badly. Not from lack of analysis, but from analyzing the wrong dimensions.
Standard evaluations focus on features, cost, and timeline. They rarely ask: Is this actually a differentiator for our business? Can we realistically execute and maintain this? What happens to careers when this fails?
What you need is a framework that accounts for strategy, capability, and risk, not just price and features.
I use three pillars:
Strategic Necessity: Is this identity capability a commodity (everyone needs it, no one cares how you do it) or a differentiator (customers choose you partly because of this)? If it’s plumbing, don’t waste engineering talent on it.
Execution Reality: Can your team actually build and maintain this? Not “do we have smart engineers” but “do we have identity security experts, dedicated headcount, 24/7 incident response, and executive commitment for the next three years?”
Total Risk: What happens if this fails? If you build and it breaks, you own it. Your career is on the line. If you buy and it breaks, you blame the vendor and switch providers. The risk is asymmetric.
These three factors determine whether you should build, buy, or find a hybrid approach.
Pillar 1: Strategic Necessity: Plumbing vs Product
The first question is the most important: does this capability actually matter to your business, or is it just infrastructure you need to keep the lights on? Most identity capabilities are table stakes. Employee SSO, password resets, basic MFA. Every company needs these. They must work reliably, or your business suffers.
But no customer chooses your product because your SSO is better than a competitor’s. These are essential infrastructure, not competitive differentiators. Your users expect seamless authentication. They don’t evaluate how you built it.
Critical? Yes. Differentiating? No. That distinction matters.
Then there are the rare cases where identity is the product. Netflix’s account sharing controls. Stripe’s developer authentication experience. AWS IAM. These companies win deals partly because of how they handle identity. For them, building makes sense.
Here’s the test: Can you name a competitor who wins or loses deals based on this specific identity capability?
If the answer is no, you’re looking at plumbing. Buy it. Your engineering team should be building features that generate revenue or create competitive advantage, not reinventing OAuth flows.
If the answer is yes, keep reading. You might have a case for building.
Five questions to pressure-test this:
- Is this customer-facing or internal-only? (Internal almost always = commodity)
- Do customers mention this capability when they choose your product?
- Would “good enough” work, or do you need “best in class”?
- Does this directly impact revenue or competitive positioning?
- Could a vendor solution meet 80% of your requirements out of the box?
If you answered “commodity” to most of these, stop here. The decision is buy. You don’t need the rest of the framework.
If you answered “differentiator” to several, move to Pillar 2.
Pillar 2: Execution Reality: Capability vs Aspiration
Let’s say you passed Pillar 1. Identity is actually strategic for you. Now the harder question: can you actually execute this?
This is where most teams lie to themselves. “We have smart engineers” is not the same as “we can build and operate a mission-critical identity platform.” Building is easy. Building secure, compliant, scalable systems that doesn’t become a liability is hard.
The real test isn’t Day 0 (the initial build). It’s Day 2 (three years from now when the original engineer has left, the cert is about to expire at 3 AM, and nobody remembers how token rotation works).
Here are the questions that expose the gap between confidence and reality:
Do you have specific identity security expertise? Not “our engineers are good at backend systems.” Do they understand OAuth, OIDC, SAML, cryptographic key management? Have they built this before?
Can you dedicate a permanent team? Not part-time, not project-based. A real squad with a product owner, engineers, QA, funded annually. If this is “we’ll carve out 20% of someone’s time,” you don’t have the capacity.
Who handles the 3 AM outage? If your service goes down, revenue stops. Do you have dedicated SRE coverage, 24/7 on-call rotation, documented runbooks? Or is it “whoever built it gets paged”?
Has your security team approved this? If InfoSec hasn’t reviewed and signed off on building custom, you’re not ready. They need to be confident you can do this safely.
What’s your timeline? If you need this in 6 months, you don’t have high capability no matter how good your team is. Rushed builds fail. If you’re under time pressure, buy.
If you scored low on most of these, buy. Even if identity is strategic, you can’t execute safely.
If you scored high, move to Pillar 3.
Pillar 3: Total Risk: The Asymmetric Bet
You’ve determined identity is strategic. Your team can execute. Now the final question: what happens if this fails?
This is where the career calculus comes in. When you buy a vendor solution and it breaks, you have options. You blame the vendor, you escalate to their support, you threaten to switch providers. Your job is safe. When you build and it breaks, you own it. Your architecture, your team, your decision. If there’s a breach or a major outage, you’re the one explaining to the board why you didn’t just buy the proven solution.
The risk is asymmetric.
Here are the questions that determine how much you’re betting:
Who takes the fall if this fails? If the answer is “me” or “my director,” you’re playing with career risk. Make sure you have executive sponsorship and air cover before you commit.
What’s the blast radius? If this identity system goes down, does it impact one team or does revenue stop company-wide? The bigger the blast radius, the higher the stakes.
Are you subject to strict compliance requirements? If you need SOC2, HIPAA, or FedRAMP certification, building means you become the target of audits. You have to prove your homegrown solution is actually secure. Vendors hand you a compliance report. You hand auditors a spreadsheet and pray.
What’s your track record with legacy code? Be honest. When you build internal tools, do they get maintained and upgraded, or do they rot until someone rewrites them five years later? If your org is bad at maintaining non-revenue code, building is high risk.
Can you absorb cost overruns? Building always costs more than projected. If your budget is fixed and overruns trigger political damage, that’s risk.
High risk doesn’t mean don’t build. It means know what you’re signing up for. Make sure leadership understands the stakes. Document your reasoning. Get executive commitment in writing.
How This Comes Together: The Decision Matrix
Here’s how these three pillars come together into a decision.
Take your scores from Pillar 1 (Strategic Necessity) and Pillar 2 (Execution Capability) and plot them on a simple matrix. Strategic Necessity is your X-axis (commodity to differentiator). Execution Capability is your Y-axis (low to high). You land in one of four zones.
The Utility Zone (Low Need, Low Capability): Buy
This is the no-brainer. Identity is plumbing for you, and you don’t have the team to build it anyway. Employee SSO, basic access controls, standard compliance requirements. Buy the vendor solution. Don’t waste a single engineering hour here.
The Talent Waste Zone (Low Need, High Capability): Buy
This is the trap. Just because you can build it doesn’t mean you should. Yes, your team could rebuild Okta’s SSO. But why? Your engineers should be working on features that differentiate your product and generate revenue, not reinventing commodity infrastructure. Buy it and move on.
The Danger Zone (High Need, Low Capability): Partner or Hybrid
You need differentiation, but you lack the skills to build safely. This is where most disasters happen: ambitious projects, under resourced teams, career ending failures. Your best option is to buy a flexible platform and pay experts to customize it heavily. You get the differentiation without owning the core security risk.
The Innovation Zone (High Need, High Capability): Build
Identity is a competitive differentiator for you, and you have the team to execute. This is the only quadrant where building makes sense. But even here, Pillar 3 matters.
The Risk Overlay
Even if you land in the Innovation Zone, check your Pillar 3 score. High risk means you need executive air cover, documented reasoning, and a backup plan. Medium risk means proceed with caution and strong project governance. Low risk means you’re as safe as you’re going to be.
This framework won’t make the decision for you. It’s not a calculator. It’s a thinking tool that forces you to confront the questions most teams skip.
Common Mistakes to Avoid
Before you make your final decision, watch out for these traps:
The “Not Invented Here” Syndrome: Engineers love to build. Just because you can doesn’t mean you should. Every hour spent building commodity features is an hour not spent on competitive advantage.
Underestimating Day 2 Maintenance: The system needs ongoing security patches, bug fixes, and compliance updates. As it integrates with more systems, complexity compounds. APIs change. Dependencies break. Authentication flows fail when upstream services update. What started simple becomes a maintenance web. The burden never stops, it only grows.
Hidden Costs: Building looks cheaper on paper. In reality, you delay time to market, lock up expensive engineering resources, and accumulate technical debt that costs more long term than the vendor solution ever would.
Ignoring Your Track Record: Look at your organization’s history with internal tools. If custom systems typically rot into unmaintainable code that nobody wants to touch, that pattern won’t change. Building carries higher risk than the spreadsheet shows.
Making the Decision
Most build vs buy decisions fail because teams skip straight to the spreadsheet. They calculate TCO, compare vendor quotes, and think they’re done. Then two years later they’re explaining to the board why the $2M investment hasn’t delivered value, or why the custom-built system became a security liability.
The real decision isn’t about cost. It’s about strategy, capability, and risk tolerance.
Use this framework before you commit. Walk through all three pillars honestly. If you’re being truthful with yourself, the answer usually becomes obvious. Commodity capabilities with low internal expertise? Buy without guilt. Strategic differentiator with a proven team and executive support? Build with confidence. Everything else? Tread carefully.
And remember: the goal isn’t to always build or always buy. The goal is to make a decision you can defend in two years when someone asks why you chose this path.
What’s Next
If you found this framework useful, I’d love to hear how you applied it. What did I miss? What would you change? Drop a comment below.
I’m also working on an interactive tool that walks you through these questions and generates a recommendation with specific risk warnings. If you want early access when it’s ready, let me know in the comments or send me a message.