Authentication was eating 30% of our sprint capacity

Nobody designs three authentication flows. You arrive at them one reasonable decision at a time, and by the time we had scaled from 200 to 2,000 business customers those three flows were consuming 30% of our engineering sprint capacity. Nearly a third of everything we built, going into a system no customer has ever named as a reason they chose us. Then $180,000 in enterprise ARR stalled on SAML, and the argument ended.

Social9 is a social media management platform for marketing agencies and in-house social teams - scheduling, publishing, analytics and collaboration across LinkedIn, X, Facebook and Instagram.

This post is not about any of that. It is about the least glamorous system we own, and how it quietly became the most expensive one.

Key Takeaways

• Three login flows, each individually defensible, together a standing tax: every security change had to be made three times.
• The real cost was not any single bug. It was 30% of sprint capacity, on a system with no user-facing value.
• Technical debt stays deferrable while it only hurts you. Ours stopped being deferrable at $180,000 in stalled ARR on a 30-day buyer timeline we did not control.
• Consolidation took six weeks in four phases with zero downtime. No user was asked to reset a password or re-authenticate.
• Six months later: sprint capacity on auth 30% to under 5%, enterprise SSO customers 0 to 37, onboarding 8 minutes to 2 minutes.
• "We should refactor authentication" loses every prioritisation meeting. "Authentication is consuming 30% of our sprint capacity and has stalled $180K" wins. Same project, one hour of arithmetic apart.

How you end up with three login flows

Nobody designs three authentication flows. You arrive at them, one reasonable decision at a time.

The first one is the original: email and password, written early, when we had a couple of hundred customers and login was a thing we needed rather than a thing we thought about. It worked fine.

The second arrives when someone asks for social sign-in. Signing in with an account users already have is genuinely better for them, and the integration is not hard. But it is not the same code path - different session establishment, different account state, different edge cases. So it becomes its own flow, sitting alongside the first, sharing some of it.

The third arrives with a customer big enough to have requirements. Something bespoke gets built for them, on a deadline, and it never gets folded back in because there is always something more urgent than refactoring authentication that currently works.

Now you have three. Each was defensible. Together they are a liability, and by the time we had scaled from 200 to 2,000 business customers the bill was arriving in four ways:

Every security change is three changes. Session expiry, password policy, rate limiting on login - you implement each one three times, and you find out you missed one when a customer reports something odd.

The flows disagree in ways users notice. Sign in one way and you land somewhere; sign in another way and the experience differs slightly. Individually trivial. Collectively they read as a product that is not quite finished.

Bugs are expensive to even locate. "I cannot log in" starts with working out which of three paths this user is on, which is not always obvious from the data.

Nobody holds the whole picture. The person who wrote the first flow is not the person who wrote the third. Reviewing a change to any of them means reconstructing intent from code.

Here is the number that ended the argument internally: authentication was consuming 30% of our engineering sprint capacity. Nearly a third of everything we built, going into a system with no user-facing value, that no customer has ever named as a reason they chose us.

That is the real cost of auth debt. Not any individual bug - the standing tax.

Then it stopped being an internal problem and started being $180K

Technical debt is easy to defer because it only hurts you. It stops being deferrable when it starts costing revenue.

For us that was two enterprise deals worth $180,000 in combined ARR, both stalled on SAML single sign-on, both with a 30-day timeline attached.

A large agency or an enterprise social team does not treat SSO as a preference. Their security policy requires that access to every SaaS tool is federated through their identity provider and revoked centrally when someone leaves. If you cannot do that, you are not a vendor they are permitted to buy, regardless of how much the team using the product wants you.

And the timelines are not ours to set. A buyer with a thirty-day window is not being difficult; they are working to a quarter or a contract end date. "We can build that next quarter" is a no.

Building SAML properly into three separate authentication flows was not something we were going to do in thirty days. That was the moment the conversation changed from "we should clean this up eventually" to a decision with a number attached.

Six weeks, four phases, zero downtime

We consolidated onto SSOJet over six weeks, in phases, without downtime.

Weeks 1-2 - Foundation. Core authentication onto one implementation: email and password, multi-factor, password reset, session management. Every subsequent security decision became one decision instead of three.

Week 3 - Social sign-in. Google, Microsoft, LinkedIn and Facebook, with account linking, so that a user who signed up one way and later signs in another way ends up in the same account rather than a mysterious duplicate. Account linking is the part people underestimate; the OAuth integration is easy and reconciling identities across providers is not.

Weeks 4-5 - Enterprise SSO. SAML 2.0 and OIDC against Azure AD, Okta and Google Workspace. This is the part that was blocking deals, and it went from a multi-month project to a connection we configure per customer - which matters more than the initial build, because every enterprise customer after the first one is now setup rather than engineering.

Week 6 - Team management. Workspace isolation, role-based permissions, invitation flows. Agencies have genuinely complex structures - staff working across multiple client accounts with different permissions in each - and this is the part that has to fit the customer's org chart rather than our data model.

The rollout was gradual and no user was asked to reset a password or re-authenticate because of it. If you are planning something similar: the migration strategy matters more than the platform choice. Anything that makes a customer's users notice will cost you more in support and goodwill than the entire project saves.

Six months later

The 30% to under 5% line is the one I would point at. That is roughly a quarter of our total engineering capacity handed back to the product, permanently, by a six-week project.

The business impact went further than we modelled. Enterprise deals that previously stalled on authentication requirements now close 45% faster, and our customer acquisition cost in the enterprise segment fell 28% as those cycles shortened. We did not set out to change CAC. It turns out that a deal which does not stall is a cheaper deal.

Going from zero enterprise SSO customers to 37 in six months is the part that surprised me most. The demand was already there. We had simply been unable to serve it, and we had no way to see it in the funnel - which is its own lesson.

What I would tell you

Count the tax before you argue about the project. "We should refactor authentication" loses every prioritisation conversation it enters. "Authentication is consuming 30% of our sprint capacity and has stalled $180K in ARR" is a different conversation entirely, and it takes about an hour to work out. We should have measured it a year earlier than we did. The number was always there; nobody had added it up.

Consolidate before you add. Our instinct when SAML became urgent was to bolt it onto what we had. That would have produced a fourth flow, and we would be writing this post again in two years with a worse story.

About the numbers in this post

Every figure here is Social9's own engineering and pipeline data. The 30% and under-5% sprint capacity figures come from tagging completed sprint work that touched authentication and taking it as a share of total capacity, before the project and six months after. The support ticket, onboarding and adoption figures are measured over the same six-month window.

No third-party benchmark is quoted and none is implied. Your numbers will depend on how much authentication debt you have accumulated and how much of your pipeline is blocked by procurement requirements rather than product fit.

Disclosure: Social9 pays for and runs SSOJet in production for authentication and enterprise SSO. This post is our account of that project. We were not paid to write it, and SSOJet has published their own version of the same story.

Frequently asked questions

How do you actually measure what authentication costs you?

Go through the last two or three quarters of completed sprint work and tag anything that touched authentication: bug fixes, security changes, support escalations that turned into engineering time, and bespoke work done for one large customer. Add it up as a share of total capacity. It took us about an hour, and it produced the 30% figure that had been true for a long time without anyone knowing it.

Is having multiple login flows really a problem if they all work?

They work individually; the cost is in every change after that. Each security decision has to be implemented and verified three times, each bug report starts with determining which path the user is on, and no single engineer holds the whole picture. It is not a correctness problem, it is a rate-of-change problem, which is why it stays invisible until you measure capacity rather than defects.

Why could you not just build SAML in 30 days?

Because we would have had to build it into three separate authentication flows, each with its own session establishment and account state. SAML against a single consolidated implementation is a contained piece of work. SAML against three divergent ones is three integrations plus the reconciliation between them, and none of that fits a buyer's 30-day window.

What makes account linking harder than the OAuth integration?

The OAuth part is well documented and largely mechanical. The hard part is deciding what a returning user is. Someone who signed up with email and password and later clicks "sign in with Google" using the same address should land in their existing account, not a duplicate. Providers can return different addresses for the same person, or unverified addresses you must not trust for matching. Each of those needs a policy decided in advance.

How do you consolidate authentication without forcing a password reset?

By phasing it and running the new implementation alongside the old rather than cutting over. Users move as they authenticate normally, and nothing about the transition is surfaced to them. It is more work than a cutover, and it is the difference between a project your customers never learn about and one that generates support volume for a month.

Why would authentication work affect customer acquisition cost?

Because a stalled deal is an expensive deal. Every additional week in an enterprise cycle consumes sales and solutions-engineering time against the same contract value. When deals that used to stall on a security requirement close 45% faster, that time comes back across the whole pipeline. We did not model this in advance; the 28% reduction in our enterprise segment was a second-order effect we noticed afterwards.

Conclusion

Three defensible decisions produced one indefensible system, and it cost us roughly a third of our engineering output for longer than we would like to admit. The thing that fixed it was not a technical insight. It was an hour of arithmetic that turned an unwinnable prioritisation argument into an obvious one.

Six weeks later we had one authentication implementation, enterprise SSO as a per-customer configuration, and 37 enterprise customers who had been unable to buy from us before.

If you suspect you are in the same position, do the hour of arithmetic first. The project does not need a better argument. It needs a number.

Social9 uses SSOJet for authentication and enterprise SSO. Their write-up is here.