CENTRAL CODE STATIONEngineering
Why we built our own identity server instead of buying one
SSO vendors solve about 80% of the problem and charge for the other 20% forever. Here's the actual math behind CCS Identity Server, and when we'd tell a client not to do the same.
Every new client engagement hits the same fork in the road within the first week: who logs in, what can they see, and how do we prove it's really them. It's not an interesting problem to solve from scratch, and it's also not one you can skip. So most teams reach for a vendor.
The question every new project asks
Auth-as-a-service vendors are genuinely good at the basics — login screens, social sign-in, password resets. What they're less good at is the part that shows up six months later: custom role hierarchies, multi-tenant permission boundaries, and the moment your pricing tier changes because your monthly active users crossed a threshold you didn't know existed.
We hit that wall on three separate client projects before we stopped treating it as bad luck and started treating it as a pattern.
What a vendor SSO actually costs over three years
The sticker price on most identity platforms looks reasonable until you model three years of growth against it. Per-active-user pricing, add-ons for role-based access control, a surcharge for audit logs your compliance team will eventually ask for — none of these show up on the pricing page you compared during evaluation.
- Per-user costs that scale faster than the value they add once you're past a few thousand accounts
- Enterprise features like fine-grained RBAC frequently gated behind the top pricing tier
- Migration lock-in: moving identity providers later means touching every service that authenticates against it
What building it once actually cost us
CCS Identity Server took real engineering time to build the first time — that's not in dispute. What changed the math was reuse. We amortize that initial cost across every client project and every internal product that plugs into it, instead of paying a recurring per-seat tax on each one independently.
The practical effect: a new engagement starts with SSO, roles, and session management already solved on day one, at zero marginal cost beyond integration time. That's the same trade-off described in our case study on building faster without cutting quality.
When we'd tell a client to buy instead
This isn't a blanket "always build" argument. If you're validating a product idea with your first ten users, a vendor's free tier is the right call — the goal is speed, not architectural purity. Buying makes sense when:
Building only pays off when you're going to reuse the foundation more than once. If this is a single, one-off product with no sibling projects on the roadmap, the vendor's ongoing cost is smaller than the engineering time it would take you to catch up to what they've already built.
- You need to validate a concept before committing to any infrastructure decisions
- Your compliance requirements are narrow enough that a vendor's default configuration already covers them
- You don't have — or don't plan to have — more than one product that would ever reuse the same identity layer
FAQ
Is a self-built identity server more secure than a vendor's?
Not automatically — security depends on implementation quality, not on who owns the code. The advantage of building once and reusing is that the same audited, tested identity layer gets hardened across every project instead of each client shipping a slightly different version of the same risk.
How long does it take to integrate CCS Identity Server into a new project?
For a typical engagement, identity, roles, and session management are wired in during the first sprint — usually before any customer-facing feature work begins.
Does this replace the need for a vendor entirely?
No — for early-stage validation or teams with only one product on the roadmap, a vendor's free or entry tier is usually still the faster, cheaper path. The build-vs-buy decision depends on whether the foundation gets reused.