Start with Identity
Subscribe
← Guides
buyer-guides · Intermediate

Build vs buy identity: the honest math

By Deepak Gupta · Updated 2026-01-15 · 12 min

The default answer is buy

For 95% of teams, building identity in-house is wrong. Not because building it is hard (it isn't, for the basics) but because maintaining it at production quality across the long tail of edge cases takes more engineering than the founders predicted.

The honest cost of "build"

Assume one senior engineer for 3 months to ship v1 ($75K loaded). Assume 0.25 of one engineer ongoing for security patches, compliance evidence, SDK updates, and new feature requests ($65K per year ongoing). Year 1 total: $140K. Year 3 total: $270K.

That's before the first SOC 2 audit makes you implement the IGA controls a vendor would have shipped by default.

The cost of "buy" at scale

CIAM vendor pricing at common scales (rough mid-2026 estimates):

  • 10K MAU: $15-25K annual
  • 100K MAU: $50-100K annual
  • 1M MAU: $200-400K annual

Crossover with "build" happens around 1M MAU for most teams, later for teams whose product UX requirements are minimal.

When to actually build

  • You are a hyperscale consumer platform (10M+ MAU) where the per-MAU economics break vendor pricing
  • Your product is itself an identity platform (vendors selling to other devs)
  • You have a regulatory environment that prohibits the available vendors
  • You have an in-house security and platform engineering team that operates production identity systems already

When to buy

  • Everyone else
  • Especially: anyone who hasn't yet shipped v1
  • Especially: anyone whose product is not "identity"
  • Especially: anyone planning to chase SOC 2 in the next 18 months

The middle path: open source self-hosted

For teams uncomfortable with vendor lock-in but unable to justify full custom build, consider self-hosted open-source CIAM (SuperTokens, FusionAuth, Keycloak). The economics improve at scale, the operational cost is real but bounded, and the code is portable.

Common pitfalls

  • Building because of "vendor lock-in concerns" without quantifying the switching cost
  • Underestimating the long tail (account recovery, edge cases, support burden)
  • Counting only the visible engineering work, not security/compliance/SDK maintenance
  • Building without designing for migration to a vendor later