Magic Links vs Passwords: What to Ship for Your AI-Built MVP

Open any app generated by Lovable, Bolt, or v0 in the last year and the authentication screen will almost always look the same. A single email field, a blue button that says "Send magic link," and no password field anywhere. That default exists for good reason. Supabase Auth and Clerk, which sit behind most AI builders, ship magic link as the lowest-friction path to a working signup flow, and for a demo or a weekend project the choice is almost invisible. The problems begin the moment real users arrive, the moment the app touches money or customer data, and the moment the first enterprise buyer asks whether the product meets their security baseline.

This article is for the founder who shipped in Lovable, got past the first fifty signups, and is starting to feel that their auth choice is load-bearing in ways the AI builder never flagged. It covers when magic link is the correct default, when a password is the better answer, where OTP fits, how passkeys change the math, and the hybrid pattern we recommend for any app that wants to survive contact with real B2B buyers.

Why Magic Link Is the AI-Builder Default

Magic link auth works by emailing the user a one-time URL that signs them in when clicked. There is no password to store, no reset flow to build, no complaint thread on Reddit about weak password requirements. For an AI code generator trying to produce a working app in one shot, that simplicity is an enormous win. The generated code is shorter, the surface area for bugs is smaller, and the product feels modern in a way that a password form never quite does.

For a consumer app with no sensitive data, that default is often correct. The user signs up once, clicks through, and is in. On the return visit, a session cookie carries them in and they never think about auth again. Substack, Notion, Slack's original desktop flow, and countless indie SaaS products shipped magic-link-only auth successfully for years.

The problem is that the AI builder does not know what kind of app is being built. It defaults to magic link whether the app is a photo-sharing toy or a financial dashboard that handles client money. The default is a starting point, not a verdict.

The Magic Link Failure Mode Nobody Warns Vibe Coders About

Most content on magic link auth talks about delivery delays and spam folders. Those are real issues, but they are not the failure that quietly kills B2B deployments. The failure that does is link prefetching by enterprise email security products.

When an email arrives at a corporate Outlook or Gmail Workspace inbox protected by Microsoft Defender Safe Links, Mimecast, Proofpoint, Barracuda, or any of a dozen similar products, the security scanner opens every URL in the email before the user sees it. The scanner is checking for malware and phishing destinations. It loads the page, sometimes follows redirects, and returns a verdict. This happens in milliseconds, before the email even lands in the inbox.

If the magic link is single-use, which it almost always is, the scanner consumes the token. By the time the user clicks the link in their inbox, the token is already burned. The user sees an error page that says the link has expired or has already been used. They try again, get another email, and the same thing happens. Support tickets pile up. The enterprise user concludes the product is broken, and the deal stalls.

There are fixes. The landing page can require a confirm-button click before exchanging the token, which survives prefetch. The magic link can be paired with a short numeric code the user types into the app instead of clicking through. Every serious auth provider now supports one of these patterns, but the AI builder almost never enables them by default, and the Lovable-generated app ships with the naive version.

If the app is going anywhere near an enterprise inbox, this single issue is reason enough to revisit the auth stack.

When Password Still Wins, and How Passkeys Change the Math

Passwords get a bad reputation they partly deserve. Users reuse them, choose weak ones, and fall for phishing. But a password has one property that magic link does not: it does not depend on an external delivery channel. The user can sign in from an airplane, from a device where their email is not logged in, from a coffee shop with flaky wifi that is blocking the auth domain. They can sign in when their IT department has broken magic links for the quarter. Password auth is resilient in a way that link-based auth is not.

That resilience matters for power users and for B2B. A sales engineer demoing to a prospect does not want to wait for an email. A customer-success rep logging into three internal tools in a row does not want three inbox trips. For any app where the user signs in more than once a week, a password is faster and less annoying than a magic link, no matter how elegant the email copy is.

Passkeys are the real story in 2026, though, and any article that frames this as a two-way choice between magic link and password is already out of date. A passkey is a cryptographic credential stored in the user's device keychain, Google Password Manager, iCloud Keychain, or 1Password. The user authenticates by touching a fingerprint sensor or typing their device PIN. There is no shared secret for an attacker to phish or for a server to leak. Passkeys are phishing-resistant by design, and the major platforms now sync them across devices in the user's ecosystem.

The correct default for most returning-user flows is passkey-first with password as fallback. On first visit the user creates an account with either a password or a magic link, and immediately the app prompts to add a passkey. On the second visit and every visit after, the passkey flow is the primary button, and the password is a secondary link for the rare case where the user is on a device without their keychain. Magic link can stay as a recovery option for account loss.

The practical effect is that most returning users never type a password again, you never deal with reset abuse, and your phishing surface collapses. This is the pattern Google, Apple, Microsoft, and GitHub have all rolled out, and the AI builders will be shipping it as default within a year. Until they do, it is worth retrofitting.

OTP: The Mobile-Only Answer, With Caveats

One-time passcodes sent by SMS sit in a strange middle ground. They solve one real problem, which is that on a mobile device typing a password or clicking a magic link and being thrown to an inbox is genuinely painful. For a mobile-first app where the phone number is effectively the user identity, such as a rideshare, delivery, or messaging product, SMS OTP at signup is the right default. The phone is the credential, the carrier is the delivery channel, and the friction is lower than any alternative.

For anything else, SMS OTP is a trap. It is expensive at scale, with Twilio SMS running roughly a cent per segment domestically and ten times that internationally, which turns auth into a five-figure monthly line item for a mid-sized consumer app. It is unreliable, with carrier delivery failures that are impossible to debug from the application side. Most importantly, it is weak as a security mechanism. SIM swap attacks have been used to drain crypto wallets, take over corporate accounts, and bypass bank security. NIST deprecated SMS as an acceptable second factor for high-assurance accounts back in 2017, and the threat has only gotten worse.

TOTP, the six-digit code generated by an authenticator app like Google Authenticator or 1Password, is a strictly better second factor than SMS. The seed is stored in the app, not in a carrier database. There is nothing for an attacker to social-engineer. For any app that touches money, admin privileges, or customer data, TOTP is the minimum modern bar, and SMS should be a fallback at best.

Email OTP, where a short numeric code is emailed instead of a link, is often a better choice than magic link for B2B. It sidesteps Safe Links prefetch entirely because the scanner cannot consume a code the user has to read and type, and it is a one-line config change in most auth providers.

The B2B 2FA Floor Every AI-Built App Misses

Any B2B SaaS app that touches customer data needs two-factor auth enforced on at least the admin and billing roles. This is not a stylistic choice. It is the baseline that SOC 2 CC6.1, ISO 27001 A.9.4.2, and every enterprise security questionnaire will expect. A single-factor auth method, whether password or magic link, does not satisfy the control in any defensible reading.

What the Lovable-generated app almost always ships is single-factor magic link across every role. When the first enterprise prospect sends a security questionnaire, the answer to "do privileged accounts require MFA" is no, and the deal stalls in procurement for weeks while the team bolts on 2FA under pressure.

The fix is not hard, but it has to be designed in rather than duct-taped. Every serious auth provider, including Clerk, WorkOS, Auth0, Supabase Auth, and Stytch, supports TOTP enrollment and per-role enforcement. The pattern that holds up under audit is that regular users can sign in with passkey, magic link, or password, while accounts with admin, billing, or data-export permissions are required to have TOTP enrolled and prompted on every sign-in.

For enterprise customers, SSO through SAML or OIDC becomes table-stakes above roughly 50,000 dollars of annual contract value. Building SSO from scratch is a multi-week project. WorkOS, Clerk, and Stytch all offer SSO as a managed feature that can be turned on per-customer, and this is almost always the right choice over rolling your own.

The Hybrid Pattern We Ship on High-Trust Apps

The pattern that holds up across the full range of customers looks like this. On signup, the user is offered a choice between passkey and email, with magic link and password as the two email options. Passkey is the recommended path, framed as "sign in with your face or fingerprint," because that is what the user actually sees. The email path is there for users on devices without keychain support and as a recovery channel.

If the user picks the email path, they get a magic link with a short numeric code included in the email. The landing page works either way, so that when Safe Links consumes the link, the user can still type the code from their inbox and get through. If the user picks password, they set one on first use with passkey promoted strongly on the next screen.

On return visits, the primary button is always passkey. Magic link and password are secondary. The app detects whether the device has a passkey registered for this account and adapts the screen accordingly.

For any account with admin, billing, or data-export privileges, TOTP is required. The requirement is enforced at the auth layer, not at the application layer, so a compromised session cannot be elevated to admin without the second factor. Backup codes are generated on enrollment and shown once.

For customers on the enterprise tier, SSO replaces the whole stack. Their users never see any of the other flows. They land on an email field, the app recognizes the domain, and the flow hands off to the customer's identity provider.

This pattern sounds complex, and on paper it is. In practice, every major auth provider now ships this as a configuration rather than a build. The work is in the decisions, not the code.

How to Migrate Without Losing Users

If the current app is magic-link-only and the goal is to add passwords, passkeys, and TOTP, the migration does not have to be disruptive. The rule is to add new methods without removing old ones, let users adopt on their own timeline, and only deprecate the old methods once adoption crosses a threshold.

The order of operations that works is passkey first, then TOTP for privileged roles, then password as a tertiary option, then email OTP as a Safe Links workaround, then SSO for enterprise. Each step can ship independently and measure its impact. Passkey adoption on the next-visit prompt typically runs forty to sixty percent in the first month on consumer apps and somewhat lower on managed corporate devices. That single step usually removes the largest chunk of auth friction.

The mistake to avoid is a big-bang cutover that forces every user to re-enroll. It will tank activation and generate a support flood. Layering is slower and safer.

When to Call a Human

Auth is one of those parts of an app where the cost of getting it wrong is not felt at build time. The AI builder ships a working flow, the first users get through, and everything looks fine. The cost shows up later as stalled enterprise deals, support tickets from Outlook users, security-questionnaire failures, and the nagging sense that the stack will not survive the next compliance review.

If you have shipped a Lovable or Bolt app, you are past the demo, and any of the following apply, it is worth getting a second set of eyes on the auth architecture. Your app touches customer data or money. You have had a prospect ask about SOC 2 or send a security questionnaire. Your support queue has complaints about expired or broken magic links. Your user base includes anyone on a managed corporate inbox. You are thinking about an enterprise tier and realising SSO is not on the roadmap.

WitsCode runs auth-method consultations for vibe coders who shipped fast with an AI builder and now need the auth stack to hold up. One session maps the current flow, identifies the failure modes that will bite first, and produces a concrete migration plan with provider recommendations and effort estimates. It is faster than building it twice, and it is cheaper than losing the first enterprise deal over a security question you could have answered yes to.

-> Book a WitsCode auth-method consultation and get the hybrid pattern configured for your app before the next deal hinges on it.