CENTRAL CODE STATIONEngineering
The real cost of rebuilding auth for every client project
We used to build authentication from scratch on every engagement, like most shops do. Here's what tracking that cost across a dozen projects actually showed us.
Early on, every new engagement started the same way: a fresh login screen, a fresh roles table, a fresh password-reset flow. It felt like due diligence. In hindsight, it was a habit we'd never actually measured the cost of.
A habit nobody questions
Building auth from scratch feels like "real" engineering work — it's concrete, it's testable, and clients can see it in a demo quickly. That visibility is exactly why it's easy to keep doing without asking whether it's the best use of the first two sprints.
What we tracked across a dozen projects
We went back through time logs on twelve past engagements and isolated everything spent on authentication, roles, and session management specifically — not the product features layered on top, just the plumbing.
- An average of roughly three working weeks per project spent on auth-adjacent infrastructure alone
- Nearly identical code written independently on eight of the twelve projects, with only cosmetic differences
- At least one security-relevant bug in early versions of that custom code on four of the twelve projects
The costs that don't show up in a sprint estimate
The sprint estimate only captures the time to write the code. It doesn't capture the cost of a client asking, six months later, why role permissions behave slightly differently than they expected — because the edge cases in a rushed, from-scratch implementation rarely get the same scrutiny as a foundation that's been used, tested, and hardened across multiple projects already.
What changed once we stopped
Once CCS Identity Server existed as a reusable foundation, that same three weeks per project largely disappeared from new engagements. It shows up directly in our case study on building faster without cutting quality — the team in that story started their first sprint with identity already solved, not as their first deliverable.
FAQ
Doesn't every project have different auth requirements?
Less often than it appears. Most projects need the same core primitives — sign-in, roles, sessions, permission checks — with different business logic layered on top. The core rarely needs to be rebuilt; the layer on top of it does.
What about projects with unusual compliance requirements?
Those get evaluated case by case. A shared foundation still helps here, since compliance-relevant code gets audited once and reused, rather than re-implemented — and re-reviewed — on every project that needs it.
How do you measure whether reuse is actually saving time?
The same way we identified the problem in the first place: tracking time spent on infrastructure versus product-specific work, project over project, and checking whether that ratio is moving in the right direction.