Better Auth

What do they actually do

Better Auth is an open‑source, TypeScript‑first authentication library you run alongside your app. Developers install it from npm, point it at their own database via adapters (Postgres/MySQL/SQLite/Prisma/Drizzle/Mongo), mount a single request handler to serve auth endpoints, and use the provided client SDK/hooks to add sign‑up/sign‑in, sessions, email verification/password reset, and social logins without wiring every piece from scratch (docs, basic usage). It includes plugins for passkeys, magic links, email OTP, two‑factor auth, organizations/teams and role/access control, plus a CLI to generate/migrate schema; example apps and a demo help teams get a working system quickly across frameworks like Next.js, Nuxt, Svelte, and others (plugins/CLI, examples, demo).

Today it’s primarily a self‑hosted library; teams keep user data in their own DB and integrate their own mail/SMS providers. The company is building a complementary managed infrastructure layer next (admin dashboard, fraud/abuse protection, transactional email/SMS, globally distributed session storage, and enterprise support), which is in waitlist/roadmap status rather than broadly available production services (build site, seed/roadmap blog). The project is public and widely used in the developer community, with the code and adoption signals visible on GitHub and recent coverage of the seed round and YC participation (GitHub repo, TechCrunch).

Who are their target customer(s)

• Early-stage TypeScript/full‑stack startups using Next/Vue/Svelte that need working auth fast.: They want drop‑in flows that live in their stack and DB so they can ship product, not build auth. They need examples and a minimal amount of custom wiring (examples).
• Small engineering teams needing customizable flows (OAuth, 2FA, passkeys, orgs/roles).: Hosted providers can be rigid or require workarounds; they want plugins/adapters to enable only what they need while keeping logic in their codebase (plugins & CLI).
• Privacy/compliance‑sensitive apps (health, finance, B2B) that must control user data.: They can’t send authentication data to third‑party SaaS and need on‑prem/cloud control with auditability. A self‑hosted, open‑source approach keeps data in their DB, with enterprise support on the roadmap (GitHub, blog).
• Teams juggling multiple identity providers and transactional channels.: Stitching OAuth, mailers, and SMS is brittle and time‑consuming; they want built‑in provider support now and a simpler transactional email/SMS path soon (social providers, roadmap).
• Growing products that expect global scale or need enterprise protections.: They don’t want to build global session storage, analytics, admin, or anti‑fraud in‑house but also don’t want to give up control of auth. They’re looking for managed add‑ons that plug into a self‑hosted core (waitlist).

How would they acquire their first 10, 50, and 100 customers

• First 10: Founder‑led, consultative installs with active GitHub users and companies who engaged via issues/stars; offer hands‑on setup, migrations, and email/SMS configuration with free implementation hours and a trial SLA.
• First 50: Turn installs into repeatable playbooks: publish step‑by‑step guides and starter repos, host weekly office hours/onboarding webinars, and convert attendees with a short managed trial and clear upgrade path to paid add‑ons.
• First 100: List on ecosystem marketplaces (e.g., hosting and ORM partners), hire a sales engineer for targeted outbound to privacy/compliance‑sensitive teams, and use early case studies plus YC/press signals to convert trials to paid add‑ons.

What is the rough total addressable market

Top-down context:

Authentication/identity sits within the broader Identity and Access Management market, which multiple analysts size at roughly $40B by 2030; the CIAM subset is a meaningful slice within that total (Grand View Research, MarketsandMarkets, GVR CIAM).

Bottom-up calculation:

If 50k–100k engineering teams globally prefer self‑hosted, TypeScript‑friendly auth, and 15%–25% of them pay for managed add‑ons (dashboard, email/SMS, security, global sessions) at $150–$500/month, the monetizable TAM for the add‑on layer is roughly $135M–$1.5B in annual spend.

Assumptions:

• Target customer base is self‑hosted and TS‑centric teams across web/SaaS products.
• Paid conversion reflects teams that want managed add‑ons on top of OSS.
• ARPU range covers tiered pricing for dashboard, messaging, and session storage with usage.

Who are some of their notable competitors

• Auth.js (NextAuth.js): Open‑source auth library you run with your app; similar self‑hosted model with adapters for databases and OAuth providers, but generally more minimal—teams often wire sessions, UI, and plugins themselves (docs, NextAuth intro).
• Clerk: Hosted identity service with drop‑in UI components, sessions, and SDKs; faster to start if you want a managed SaaS, but user data lives off your primary DB and it’s not a self‑hosted library (overview).
• Auth0 (Okta): Enterprise‑grade hosted identity platform covering SSO, enterprise connectors, and managed hosting options; powerful but heavier and paid, rather than an open‑source TypeScript library embedded in your backend (deployment options).
• Supabase Auth: Auth component of the Supabase stack; Postgres‑backed and available self‑hosted or as a managed service—appeals when teams want a database‑centric open stack beyond just auth (self‑hosting docs).
• Ory Kratos: Headless, open‑source identity server aimed at teams that want a full identity backend they operate; includes a separate managed offering and enterprise licensing for SLAs (repo, docs).