How We Went Passwordless and Scaled LogicBalls from 4K to 250K MAU

In February 2024 I pulled our Zendesk numbers to find out where support time was actually going. Password resets were 140 tickets a month — 35% of everything our support queue handled — at roughly $12 of loaded cost per incident and 8 to 12 minutes of a human's attention each.

That is $1,680 a month. Annoying, not fatal. What made it a decision was dividing it by our user count. At 4,000 monthly active users, 140 resets is a 3.5% monthly reset rate. We were planning for 250,000 MAU. Hold that rate and the same queue becomes 8,750 password reset tickets a month.

There is no version of that where we hire our way out. So we stopped treating passwords as a feature to improve and started treating them as infrastructure to remove. This is what that actually took: the evaluation, the three-week rollout, the migration path for existing accounts, and eight months of numbers on the other side.

Key Takeaways

• The reset rate, not the ticket count, is the number that matters. 140 tickets at 4,000 MAU is a 3.5% monthly reset rate. Projected onto our 250,000 MAU target that is 8,750 tickets a month — the same arithmetic turned a support annoyance into an architecture decision.
• Attack volume scales with your user table the same way. We were absorbing roughly 320 credential stuffing attempts a month at 4,000 MAU. The same per-user rate at 250,000 MAU is over 20,000 attempts a month, all of them aimed at a password database we no longer wanted to own.
• Passwordless was faster to ship than we expected: three weeks, not a quarter. Week one was configuration, week two was SDK integration and migration, week three was production rollout plus SSO into our forum and support portal.
• Users do not pick one method — they pick six. Our login mix settled at 42% one-tap, 38% Google, 12% Apple, 5% Facebook, 3% email OTP globally, with WhatsApp clearing 15% inside APAC, LATAM, and MENA. Shipping a single social provider would have missed most of that.
• The measurable wins were speed and completion, not just cost. Average login went from 23 seconds to 4, registration abandonment from 18% to 6%, mobile login success from 81% to 97%, and password reset tickets from 140 a month to zero.

The Math That Made This an Architecture Problem

Two internal numbers drove the decision, and both of them scale linearly with user count.

The first was support. 140 password reset tickets a month against 4,000 MAU, each one costing about $12 fully loaded and taking 8 to 12 minutes. Password resets were 35% of our total support volume — the single largest category, ahead of billing and ahead of actual product questions.

The second was security. Our edge logs showed roughly 320 credential stuffing attempts a month at that same 4,000 MAU baseline. Nothing exotic: automated replay of username and password pairs from breach dumps, betting on reuse. That bet is usually correct often enough to be worth an attacker's time.

Both numbers are rates, not totals. Project them onto the user base we were building toward:

There were three more costs underneath, less dramatic but constant. Registration abandonment sat at 18%, and "another password to manage" showed up repeatedly in the drop-off feedback we collected — a real objection in a market where a user's alternative is one of a thousand other AI tools. Engineering was spending 3 to 4 hours a week on password infrastructure: reset flows, hashing policy, rotation, lockout tuning. And 65% of our access was mobile, where password entry is at its worst — autofill that fires inconsistently across in-app browsers, and the keyboard switching that a "one uppercase, one symbol" policy forces on a phone.

Why We Did Not Just Add "Sign in With Google" and Move On

Adding Google OAuth alone was the cheap option, and LogicBalls seriously considered it: bolt on one social provider, cut some friction, keep the password table for everyone else.

The problem is that it does not remove anything. A password table that 60% of your users still touch is a password table: same reset flow, same hashing decisions, same breach exposure, same 3 to 4 engineering hours a week. You get a partial reduction in tickets and none of the reduction in risk, because credential stuffing does not care that some of your users switched to OAuth. It only cares that the endpoint still accepts a password.

It also would not have solved the part of the problem we could see coming. We were already serving users in 50 countries with the US as our largest market. Google's share of consumer identity is not uniform across those markets, and building a single-provider dependency into the front door of the product meant accepting whatever that provider's regional coverage happened to be.

The decision we made was that the password database had to reach zero rows, not fewer rows. Everything after that followed from that one constraint.

How We Evaluated Auth0, Firebase, Cognito, and MojoAuth

We ran the evaluation in March 2024 against four candidates: Auth0, Firebase Authentication, AWS Cognito, and MojoAuth. Four criteria, weighted in this order:

1. Passwordless as the default, not a mode. All four can technically do passwordless. The distinction we cared about was whether passwordless is the architecture or an option layered on a password-centric core — because that determines whether you can actually get to zero stored credentials or merely make passwords optional for some users. That was the criterion that did the most work in the decision.

2. Method breadth in one integration. We wanted one-tap, Google, Apple, email OTP, WhatsApp, and Facebook behind a single SDK and a single session model. Assembling six methods from separate integrations is six sets of edge cases, six token lifetimes, and six things to debug at 2am.

3. Enterprise SSO we could grow into. We were selling to marketing agencies, enterprises, and educational institutions. SAML 2.0 and JWT-based SSO needed to be present before we needed them, not on a roadmap.

4. Global coverage in the markets we were already in. 50 countries, and specifically the APAC, LATAM, and MENA markets where WhatsApp is the default identity channel for a large share of users. This is where most evaluations quietly assume a US-shaped user base.

We selected MojoAuth. The honest summary of why: the other three were credible general-purpose identity platforms where passwordless is a supported configuration, and we wanted the one where removing the password database entirely was the intended path rather than an advanced setup. The multi-method breadth in a single SDK and the WhatsApp support closed it. MojoAuth published their side of this engagement as a customer case study, and the figures in this post are the same ones we gave them.

The Three-Week Rollout, Week by Week

I had budgeted a quarter. It took three weeks, and the schedule below is what actually happened rather than what the plan said.

Week 1 — planning and configuration. Technical architecture, and mapping the migration path for existing password accounts before writing any integration code. OAuth provider configuration for Google, Apple, and Facebook. WhatsApp Business API integration. Email OTP template customization so the messages looked like us. SSO architecture planning for the forum and support portal, deliberately scoped into the same project instead of a follow-up one — a decision I would repeat.

Week 2 — development and testing. Frontend integration of the MojoAuth JavaScript SDK, React authentication components, session management and JWT handling. The migration strategy for existing password users, built and tested here. Mobile SDK integration for iOS and Android. Cross-browser and cross-device testing, which is where most of the week actually went — in-app browsers inside social apps behave differently enough from Safari and Chrome that they are their own test matrix.

Week 3 — launch and SSO. Production deployment behind feature flags, so the passwordless path could be enabled for a slice of traffic and rolled back without a deploy. A user communication campaign explaining what was changing before it changed. Discourse forum SAML 2.0 integration and Zendesk support portal JWT SSO. Monitoring dashboards configured before the rollout percentage went up, not after.

Feature flags are the reason three weeks was safe rather than reckless. Authentication is the one system where a bad deploy locks out 100% of users simultaneously, including the people who would fix it.

Migrating 4,000 Accounts Without a Forced Reset

Migrating existing accounts is the question that stalls these projects, so here is specifically how LogicBalls framed it.

A forced password reset at cutover is the simplest engineering choice and the worst product choice. It sends a "reset your password" email to every account you have — an email that is indistinguishable from a phishing attempt, arriving unprompted — and it converts your entire user base into a support event on a single day. At 4,000 users we could have absorbed it. That is not a reason to do it.

We designed the path so that existing users never encountered a password again rather than encountering one final time. The account continues to exist and is keyed on the identifier the user already had, and their next sign-in resolves to a passwordless method rather than to a credential prompt. The password column stops being read, then stops being written, then is not there. From the user's side the only visible event is that the login screen changed.

Two things made this survivable. First, doing the migration mapping in week one, before any integration code existed — the constraint shapes the integration, not the other way around. Second, the feature flags: the old path stayed live and reachable while the new one took traffic, so "roll back" was a config change rather than an incident.

What Our Users Actually Chose

LogicBalls' assumptions about login method mix turned out wrong in both directions. This is the breakdown I would have wanted before we started.

Four things in that chart surprised us.

One-tap beat Google. We had assumed social login would dominate and one-tap would be a nice-to-have for returning users. Instead the method with no logo and no decision attached to it took the largest share. Users do not want to choose an identity provider; they want to be signed in.

Email OTP is small but not optional. At 3% globally it looks like a rounding error until you notice who those 3% are. Enterprise users on managed devices, where corporate policy blocks consumer social login. Removing email OTP to simplify the UI would have removed our highest-value segment's only path in.

WhatsApp is invisible globally and decisive regionally. WhatsApp does not appear in the global mix at a size worth charting, and it clears 15% inside APAC, LATAM, and MENA. If we had evaluated method breadth on aggregate numbers we would have cut it, and cut a meaningful share of three regions with it.

Facebook at 5% still earned its place. Small, concentrated among independent creators, and cheap to keep once the multi-method integration already existed.

The general lesson: aggregate login-mix data will always argue for fewer methods, because it averages over exactly the regional and segment differences that make additional methods worth having. Look at the mix per region and per segment before you cut anything.

Unifying Three Separate Logins Into One Session

Before this project a user had three credential sets with us: the platform, the Discourse community forum, and the Zendesk support portal. Someone who hit a problem in the product had to authenticate again to ask about it, and again to search whether anyone else had. That is a friction tax applied precisely at the moment a user is already frustrated.

We folded all three into one session during week three:

• Discourse forum — SAML 2.0 integration, with automatic user provisioning so a first forum visit creates the account rather than asking for one.
• Zendesk support portal — JWT-based SSO against the same session.
• The platform itself — the primary MojoAuth session, 7-day JWT lifetime, portable across devices.

The result is one sign-in and 100% session portability across the three. The reason this belonged in the same three weeks rather than a follow-up quarter is that session design is hard to retrofit: decide token lifetime, refresh behavior, and logout propagation once, while you are already deciding them.

The Numbers, Eight Months Later

We went live in March 2024. These are the November 2024 figures against the February 2024 baseline. Growth over that window was 62x, so read the ratios rather than the totals.

Every row above is measured, not modelled. Sources are LogicBalls' own systems: Zendesk ticket volume, edge and WAF logs, product analytics, and authentication analytics. The baseline column was taken in February 2024 and the after column in November 2024.

A few of these deserve a note on how to read them.

Zero is a structural zero, not a good quarter. Password reset tickets went to zero and credential stuffing attempts went to zero for the same reason: there is no password to reset and no credential to stuff. A stuffing attempt against an endpoint that does not accept passwords is not a blocked attack, it is a category error. This is the difference between mitigating a risk and removing it — and it is why the ratio held while users grew 62x rather than degrading with scale.

Registration abandonment fell 67% while volume grew 62x. Conversion metrics usually get worse as traffic broadens, because later traffic is less qualified than early adopters. Going from 18% to 6% across that expansion is the number I would point to first if you are trying to justify this project on growth rather than cost.

Mobile is where the login time win landed. 23 seconds to 4 seconds is an 83% reduction in aggregate, and 65% of our access is mobile — the segment where the 23 seconds was worst. Mobile login success rising from 81% to 97% means roughly one in five mobile sign-in attempts used to fail outright.

The operational side, in the same window: about 12 hours a month of engineering time returned from password infrastructure maintenance, no password storage to maintain at all, 99.98% authentication uptime, and around 8,300 authentications a day across 50 countries at a 38ms average global response time. We ended the period at 400,000 registered users and 250,000 MAU — a 62.5% active ratio.

Four Things I Would Tell You to Plan For

If you are running this project, these are the four places our time actually went.

1. In-app browsers are their own test target. A meaningful share of mobile traffic arrives inside the browser embedded in a social or messaging app, and those behave differently from Safari and Chrome on redirect handling and credential access. Budget real time for this in your test matrix rather than discovering it in production.

2. Method mix is regional, so instrument it regionally from day one. We would have made the wrong call on WhatsApp from global numbers. Ship the analytics that break login method down by region and by customer segment before you ship the methods, so your first cut decision has data behind it.

3. Session and logout design is the retrofit that hurts. Getting SSO to the forum and the support portal into the same three weeks was the single highest-leverage scheduling decision, because token lifetime, refresh, and logout propagation are cheap to decide once and expensive to change across three systems later.

4. Tell users before you change the front door. The communication campaign in week three was not a marketing nicety. Any unexplained change to a login screen looks like a phishing page to a security-aware user, and looks like a broken product to everyone else.

What We Put on the Roadmap Next

Coming out of the migration, these were the next priorities we set. Listing them as the roadmap from that point rather than as shipped state:

• FIDO2 and WebAuthn passkeys, the natural next step from one-tap and the method that makes the device credential portable across our platform properly.
• Enterprise team management, driven by the same enterprise segment that showed up as that 3% email OTP slice.
• Risk-based adaptive MFA, so step-up is triggered by signal rather than applied uniformly.
• Region-specific methods as we expand past the current 50 countries — the WhatsApp lesson generalizes.
• SOC 2 Type II and ISO 27001 certification.
• API authentication for programmatic access, for customers building on top of our tools.

Frequently Asked Questions

How long does a passwordless migration actually take?

LogicBalls' migration took three weeks from planning to full production rollout, including SSO into two external systems, against the quarter I had budgeted. The scope that fit in three weeks was six authentication methods, iOS and Android SDK integration, a migration path for existing password accounts, and SAML plus JWT SSO. The largest single time sink was cross-browser and cross-device testing, not integration.

Do you have to force existing users to reset their passwords?

No, and LogicBalls would advise against it. A forced reset converts your whole user base into a support event on one day and sends an unprompted "reset your password" email that is functionally indistinguishable from phishing. We mapped the migration path in week one, before writing integration code, so existing accounts resolved to a passwordless method on next sign-in instead of to a final credential prompt.

Does going passwordless actually stop credential stuffing?

Going passwordless removes the target rather than defending it. LogicBalls' credential stuffing attempts went from roughly 320 a month to zero, because an endpoint that does not accept passwords cannot be attacked with stolen password pairs. The distinction matters for how the number behaves at scale: mitigation degrades as attack volume grows, removal does not. We grew users 62x over the same window and the figure stayed at zero.

How many authentication methods do you actually need?

More than the global numbers will tell you. LogicBalls' mix is 42% one-tap, 38% Google, 12% Apple, 5% Facebook, and 3% email OTP globally, with WhatsApp above 15% within APAC, LATAM, and MENA. The 3% email OTP slice is disproportionately our enterprise users on managed devices where consumer social login is blocked, and the WhatsApp share is invisible in aggregate. Both would have been cut on global data alone.

What does passwordless do to conversion?

LogicBalls' registration abandonment went from 18% to 6% — a 67% reduction — across a period when monthly active users grew from 4,000 to 250,000. Average login time went from 23 seconds to 4, and mobile login success from 81% to 97%. Mobile is where the effect concentrates, which matters more the higher your mobile share is; ours is 65%.

What is the actual cost saving?

For LogicBalls, about $20,000 a year in direct support cost — 140 tickets a month at roughly $12 fully loaded, taken to zero. That understates it. The projection is the real figure: holding a 3.5% monthly reset rate to 250,000 MAU would have meant 8,750 tickets a month, which is a support organization we never had to hire. Add roughly 12 hours a month of engineering time returned from password infrastructure maintenance.

Conclusion

The thing I got wrong at the start was framing this as a support cost problem. It looked like $1,680 a month, which is not a number that reorders a roadmap.

It was a scaling problem. Every cost in it — tickets, attack volume, engineering maintenance, abandoned registrations — was a rate that multiplies by user count, and we were planning to multiply user count by 62. The question was never whether to spend $20,000 a year on password resets. It was whether the front door of the product would still work at 250,000 users, and passwords are a design that gets structurally worse as you grow rather than better.

If you are looking at your own version of these numbers, run the projection first. Take your reset count and your stuffing attempts, divide by current users, multiply by your target. If the result is a number you would have to hire against, you have an architecture decision rather than a support decision, and three weeks is a reasonable budget for it.

About this post: written by Govind Kumar, CTO of LogicBalls. All before-and-after figures are LogicBalls first-party data — Zendesk support ticket volume, edge and WAF logs, product analytics, and authentication analytics — measured against a February 2024 baseline and reported as of November 2024. Our authentication provider published their account of the same engagement, using the same figures, as a case study. Projections are labeled as projections and are straight per-user-rate multiplications, not forecasts of changed behavior.