How We Shipped Passwordless Auth in 48 Hours and Grew Kveeky 80x in 30 Days

We rewrote how people log in to Kveeky on 15 and 16 October 2024. Two days. Build on the first, test and ship on the second, live at 6 PM PT.

Then we got lucky in a way that's easy to misread. Over the following thirty days Kveeky went from 1,000 monthly active users to more than 80,000, and from 2,000 registered accounts to more than 140,000. Nobody planned that. It wasn't a launch, it was creators finding us faster than we could believe.

The login layer we'd shipped 48 hours earlier carried all of it. We didn't tune it, scale it, or touch it. That's the useful part of this story, and it's not really a story about being fast — it's about what a per-user operational cost does to you when the per-user number stops being small.

These are the notes we kept.

Key Takeaways

• Two days was possible because we cut scope hard, not because auth is easy. We replaced the login method and nothing else. No onboarding redesign, no account-model change, no migration of existing credentials into a new store. What fit: five auth methods, web and mobile SDKs, a new login UI, and a flagged production rollout.
• Most of day two was testing, not building. The device matrix — iOS 15-17, Android 11-14, four browsers, 3G through WiFi, and the offline-to-online transition — took longer than the integration did. Social login redirects are the fragile part on mobile.
• The growth arrived after the fix, which is the wrong order to rely on. Had we deferred this by a quarter, the same per-user support rate would have produced roughly 3,600 login tickets a month at 80,000 MAU, on a team already spending 40% of support capacity on passwords.
• Our login-method numbers are measured on different bases, and we publish them that way. One-tap is 48% of returning users; Google 42%, LinkedIn 6%, Microsoft 4%, email OTP ~5% of all logins. They don't sum to 100 and shouldn't be forced to.
• Mobile is where the entire result showed up. 75% of our traffic is creators on phones. Mobile login success went 76% → 98%, average login 28s → 3s, registration completion 78% → 94%.

The Two Days

Kveeky replaced its password login over two working days, 15 and 16 October 2024. The log below is what fit inside those two days, because "we did it in two days" is worthless without it.

Tuesday 15 October, morning. Account setup and API keys, half an hour. OAuth provider configuration for Google, LinkedIn, and Microsoft — client IDs, secrets, redirect URIs — about an hour. The JavaScript SDK into our React web app, two hours. iOS and Android SDK integration, two hours. Email OTP templates rebranded so the messages looked like us rather than like a vendor, half an hour.

Tuesday afternoon. The login screen itself. We deleted the password form and built a mobile-first replacement: one-tap first for returning users, social buttons underneath in our own styling, email OTP present but visually subordinate as the fallback. Session management and JWT handling went in alongside it. Development-environment testing to close the day.

Wednesday 16 October, morning. Testing, and this is where the day went. iOS 15 through 17 and Android 11 through 14 across real screen sizes. Chrome, Safari, Firefox, Edge. Network conditions we could actually expect from creators: 3G, 4G, WiFi, and the offline-to-online transition that happens when someone walks into a building mid-sign-in. Social login redirect flows, which break in more interesting ways on mobile than anywhere else. Email OTP delivery timing, which is a user-experience number as much as a technical one.

Wednesday afternoon. Production configuration, then a rollout behind feature flags with new users routed to the new path first. Monitoring dashboards went up before the rollout percentage moved rather than after — that ordering is the whole point of having them. In-app notifications explained the change to existing users and invited them to link a social account. Support got briefed the same afternoon, before anyone could file a ticket about it. Go-live at 6 PM PT, all traffic on the new path, no incidents.

Feature flags are why two days wasn't reckless. Routing new users first meant a mistake would land on the cohort with the least history to lose, and backing out was a config toggle rather than a deploy at the exact moment we'd be least able to deploy.

What We Cut to Make Two Days Fit

The two-day schedule held because of what Kveeky refused to build alongside it, not because the work itself was small. Four things got deliberately cut.

We changed the login method and nothing adjacent. Onboarding stayed exactly as it was. The account model stayed as it was. Profile, billing, and the studio itself were untouched. Every "while we're in here we could also…" got written down and deferred. Authentication projects die by adjacency; each neighbouring change doubles the surface you have to test on the second day.

We didn't migrate credentials, we stopped using them. There was no batch job moving password hashes into a new store, because the destination has no credential store. An existing account kept the identifier it already had, and the first time that person came back they met a passwordless method instead of a prompt. We deliberately did not send a mass "reset your password" email — an unprompted credential email is indistinguishable from phishing, and it turns your whole user base into one day's support queue.

We accepted five methods and no more. One-tap, Google, LinkedIn, Microsoft, email OTP. WhatsApp and phone login were both things we wanted and both went on the roadmap instead of into the sprint, on the explicit understanding that adding them later would be configuration rather than a rebuild. Had that not been true, the calculus on day one would have been different.

We shipped the login screen we could test, not the one we'd design given a week. It was clean and it was ours, but it wasn't the product of a design cycle. That was the right trade at the time and we've iterated on it since.

Then the Wave Arrived

Thirty days after go-live, on 15 November 2024, Kveeky had crossed 80,000 monthly active users and 140,000 registered accounts.

Growth like that is not a thing you engineer. It came from creators finding the product and telling other creators, and it would have happened to whatever login screen was in place on 16 October.

What we can take credit for is that the login screen in place had no per-user operational cost attached to it. No reset queue that grows with the user table. No credential store to secure at a new size. No manual step anywhere in the path. Authentication uptime through the spike was 99.97%, average authentication latency held around 42ms globally, and at the end of the period we were serving roughly 2,700 authentications a day against 140,000 registered accounts and 80,000 monthly actives — a 57% active ratio. Not one of those numbers required an intervention from us during the month.

The counterfactual is the interesting part, and it's the next section.

The Bill We Never Received

Before the migration, Kveeky ran password-only authentication with no social login at all. That produced roughly 45 login support tickets a month, of which password resets were the dominant category at about 38, against 1,000 monthly active users. Direct cost was about $540 a month — call it $12 of loaded cost per ticket.

$540 a month is not a number that reorders a startup's roadmap, and we want to be honest that it nearly didn't reorder ours. What made it urgent was the share rather than the sum: password and login issues were eating roughly 40% of our support capacity. On a team our size that's not a line item, it's a person.

Then apply the growth. Both of those figures are rates per user, and the user count went up by a factor of eighty:

Baseline figures: Kveeky support ticket volume, pre-migration. Projected columns are the measured per-user rate multiplied by 80,000 monthly active users, the count Kveeky reached on 15 November 2024.

Nothing in that table assumes creators get worse at passwords or that anything degrades. It's arithmetic on a rate we'd already measured, applied to a user count we actually reached. We would have met November with a support queue we had no way to staff, in the same month we were trying to keep the AI voice pipeline up under 80x load.

There were four more costs underneath, and each had the same per-user shape.

Phone keyboards, on a product that's 75% mobile. Kveeky's creators work on phones — a YouTuber writing between takes, a TikToker turning a video around in twenty minutes, a podcaster recording from a hotel room. Asking that person to produce a password with an uppercase and a symbol on a touch keyboard, fighting autocorrect and app-switching to a password manager, contradicts the premise of a tool that promises a voiceover in seconds.

One in five sign-ups abandoned. Registration completion sat at 78%. The "create a password" step was where we lost them, and during a traffic spike that percentage stops being a percentage and becomes a count of creators who tried us once.

An English-shaped login on a 200-language product. Kveeky generates voiceovers in over 200 languages. Our password rules, error strings, and reset flow were English-centric in a way the rest of the product had stopped being.

No door for professional accounts. Marketing teams and agencies were adopting Kveeky for client work and expected LinkedIn and Microsoft SSO for work identities. Password-only was quietly capping a segment we wanted.

Reading Our Login Mix Without Fooling Ourselves

Once traffic settled we looked at which methods people actually used, and the honest answer requires paying attention to what each percentage is a percentage of.

Source: Kveeky authentication analytics, 16 October to 15 November 2024. Shares are reported on the two different bases named in the right-hand column and do not sum to 100%.

Those bases aren't interchangeable and the figures don't sum to 100. We're leaving them that way rather than normalising them into a tidier chart, because flattening them is exactly the move that gets a method deleted.

One-tap owns the repeat visit, and repeat visits are the product. A voiceover tool isn't a monthly destination. Creators come back for every video, and nearly half of that returning traffic now authenticates with no logo, no provider decision, and no typing. Being asked which account to sign in with is itself the friction; the winning option is the one that asks nothing.

LinkedIn and Microsoft are small and not noise. Ten percent of all logins between them, concentrated almost entirely in the marketing-team and agency accounts that buy the larger plans. A 6% row is cheap to cut on a slide and expensive to cut in revenue.

Email OTP is the smallest share and the only one with no substitute. It serves creators without social accounts, creators in regions where social platform access is restricted, and anyone on a corporate device where policy blocks consumer OAuth. You can't route those people anywhere else.

If we'd reviewed a single normalised pie chart, the honest reading of it would have been "ship Google and one-tap, drop the rest," and we'd have been wrong about both ends of our user base at once.

Why We Bought Instead of Built

We looked at four options in October 2024: Auth0, Firebase Authentication, AWS Cognito, and writing it ourselves. We chose MojoAuth.

Building it ourselves went first, and it went quickly. Not because it's hard to implement OAuth — it isn't — but because the thing you're signing up for is the maintenance, and the maintenance is unbounded. Provider quirks, token refresh edge cases, the security patches you don't get to defer, and the on-call surface of the one system that can lock out every user simultaneously. We're four people trying to make AI voices sound human. That is not a good use of our on-call.

Adding just Google login was the other cheap option, and it fails for a reason worth spelling out: it subtracts nothing. Whatever fraction of your users move to OAuth, the credential store is still sitting there with all its obligations intact, and the login endpoint still takes a password from anyone who types one. You buy a smaller ticket queue and no change at all in what an attacker can reach. So we set the constraint at zero stored credentials rather than fewer, and every decision after that fell out of it.

Against the three managed platforms, four things decided it:

Days, not weeks, to production. For a team our size an integration measured in weeks isn't a cost, it's the features we didn't ship instead.

Mobile-first rather than mobile-supported. Three-quarters of our traffic is touch, small screens, one hand. There's a real difference between an SDK designed for that and a desktop-shaped flow with a responsive breakpoint.

Five methods behind one session model. Assembling five integrations means five sets of edge cases and five token lifetimes to hold in your head at 2 AM.

Room to add methods by configuration. We already knew WhatsApp and phone auth were coming for creators in India, Southeast Asia, Latin America, and the Middle East. The question wasn't whether a platform supported them today, it was whether adding one later was a config change or a rebuild.

MojoAuth wrote up their side of this project as a customer case study. Every figure in this post is one we handed them.

Thirty Days of Numbers

Measured from go-live on 16 October to 15 November 2024, against the pre-migration baseline.

Source: Kveeky first-party data — support ticket volume, product analytics, and authentication analytics. "Before" is the pre-migration baseline; "after" is measured on 15 November 2024, thirty days after go-live on 16 October 2024. No figure in this table is modelled or projected.

Three of those need a note on how to read them.

The zeros aren't a good month. Login tickets and reset requests both went to zero and held there while users grew 80x. That's the absence of a category rather than an improvement in one — there's no password to reset, so the ticket type doesn't exist. It's also why the number couldn't decay under load the way a mitigation would. The same property took our password-database breach exposure to nothing, since there's no credential store to exfiltrate, and we recorded no account takeover incidents in the window.

Completion improved while the traffic got less qualified. Conversion normally sags during a spike, because a viral audience is looking around rather than looking for you. Going 78% → 94% across an 80x expansion is the figure we'd point at if we were justifying this work on growth rather than cost.

The login-time number is really a mobile number. 28 seconds to 3 is an 89% cut in aggregate, and the 28 seconds was at its worst on phones. Put next to mobile success going 76% → 98%, the practical effect is that signing in stopped being a place where creators fell out of their own workflow.

What We'd Do Differently

Four things Kveeky's engineering team got wrong during the October 2024 rollout, or got right by accident. Not advice, just what we'd change.

We should have instrumented the method mix before we shipped the methods, not after. We ended up reading login-method data that was already collected in a shape we hadn't chosen, and the base mismatch in that table is a direct consequence. Decide up front that you'll break login method down by region and account type, and you get a clean answer to "can we drop this method" instead of an argument.

We got the ordering right by luck and wouldn't rely on it again. We shipped this thirty days before the traffic that justified it. Had the wave come first we'd have been rebuilding the front door during the busiest month of the company's life, which is the worst possible time to touch authentication. If you're looking at a per-user cost that's currently tolerable, the honest question is what it looks like at the number you're hoping for, not the number you have.

The support briefing should have happened a day earlier. We briefed the support team on the afternoon of the rollout. It worked, but it worked with no margin — anyone who'd been mid-conversation with a creator that morning was answering questions about a login screen that had changed under them. A day of lead time costs nothing.

We'd still cut the same scope, and we'd write it down more visibly. Deferring onboarding, the account model, and two auth methods is why two days was two days. The deferred list lived in a doc that only three people read. Some of it we then rediscovered a month later.

Where We Took It Next

Kveeky set the following authentication roadmap at the end of the thirty-day window, in November 2024. Treat it as a snapshot of intent at that date, not a claim about what exists today:

• WhatsApp and phone authentication for creators in India, Southeast Asia, Latin America, and the Middle East, where messaging apps are the default identity channel — configuration rather than an infrastructure rebuild, which was the whole reason we cared about that property in October.
• FIDO2 and WebAuthn passkeys, the natural step past one-tap, and the method that removes phishing risk rather than reducing it.
• Team workspaces for agencies and creator studios: role-based access, member provisioning, unified billing.
• Region-specific methods as we expand — WeChat, LINE, Kakao — on the same reasoning that put WhatsApp on this list.
• Creator API authentication for programmatic access, automation workflows, and third-party integrations.
• Enterprise plans for creator studios, built on the SSO and team layer rather than as a second authentication path.

Frequently Asked Questions

Can a passwordless migration really be done in two days?

Kveeky's was, over two working days on 15-16 October 2024, and the breakdown matters: day one was building, day two was mostly testing. Inside the 48 hours were platform configuration, OAuth setup for Google, LinkedIn and Microsoft, the JavaScript SDK into a React app, iOS and Android SDK integration, a rebuilt mobile-first login screen, session and JWT handling, a full cross-device test matrix, and a feature-flagged production rollout. What made it fit was refusing to touch onboarding, the account model, or anything else adjacent at the same time.

What happens to existing users when you remove passwords?

Nothing they have to do. At Kveeky, existing accounts kept the identifier they already had, and whoever came back next simply met a passwordless method instead of a prompt. There was no batch migration at all, because the destination has no credential store to migrate into. We rolled out behind feature flags with new users on the new path first, and told existing users through in-app notifications rather than email. We specifically avoided a mass "reset your password" send — unprompted credential email reads as phishing to careful users and creates a single-day support spike from everyone else.

Does passwordless actually help mobile users, or is that a vendor claim?

For Kveeky it was the single largest effect. Mobile login success went from 76% to 98% and average login time from 28 seconds to 3. How much that matters scales with your mobile share, which for us is 75%. The mechanism isn't subtle: one-tap and social login remove text entry from a touch keyboard, and with it autocorrect interference, password-manager app-switching, and the shift-key work a complexity policy forces on a phone.

Is one social login enough, or do you need five?

More than a normalised chart will suggest. Kveeky's mix runs 42% Google, 6% LinkedIn, 4% Microsoft and about 5% email OTP across all logins, with one-tap separately serving as the primary method for 48% of returning users. LinkedIn and Microsoft together are 10% and they sit almost entirely in the B2B accounts on larger plans. Email OTP is the smallest number in the table and the only one with no fallback behind it, since it serves corporate devices and regions with restricted social access.

What did it save?

Kveeky's authentication support cost went from about $540 a month to about $50 — roughly 90%, or $5.9K a year. That figure undersells it. The real number is the one we never paid: holding a 4.5% monthly login-ticket rate against the 80,000 MAU we hit thirty days later works out to about 3,600 tickets a month, which is a support team we never had to hire. Add the engineering time not spent on credential storage, reset flows, and security patches.

Does removing passwords reduce breach risk or just relocate it?

Removing passwords removes the asset. With no stored credentials there's no password database to exfiltrate, which is why we report zero breach exposure and zero account takeover incidents for this window rather than a reduced count. The distinction shows up under load: a mitigation has to keep working as attack volume grows, whereas an absent credential store has nothing to keep working. Users grew 80x across the measurement period and that property was unaffected.

Conclusion

The mistake we nearly made was reading this as a support-ticket problem. At $540 a month it doesn't clear the bar for a small team's engineering time, and we could have pushed it two more quarters without anyone objecting.

It was a per-user problem wearing a support problem's clothes. Tickets, reset requests, abandoned sign-ups, failed mobile logins, the engineering hours — every one of them was a rate, and thirty days after we shipped, the thing those rates multiply by went up eighty times.

We're not going to pretend we saw that coming. We didn't. What we'd say instead is that the cost of being wrong about timing is asymmetric: shipping this a quarter early cost us two days, and shipping it a quarter late would have cost us the month that made the company. If you can see a per-user cost in your own numbers, the useful question isn't what it costs now. It's what it costs at the number you're building toward — and whether you'd rather find out before or after you get there.

About this post: written by the Kveeky engineering team. All before-and-after figures are Kveeky first-party data — support ticket volume, product analytics, and authentication analytics — measured against the pre-migration baseline and reported as of 15 November 2024, thirty days after go-live on 16 October 2024. Our authentication vendor's write-up of the same project, drawn from the same dataset, is here. Login method shares are reported on the bases stated in the table and do not sum to 100%. Where we project a figure we say so and show the arithmetic: it is a measured per-user rate multiplied by a user count, and it predicts nothing about how anyone's behaviour changes. More about the platform at kveeky.com.