Get AI summaries of any video or article — Sign up free
First Block: Interview with Julianna Lamb, Co-Founder & CTO of Stytch thumbnail

First Block: Interview with Julianna Lamb, Co-Founder & CTO of Stytch

Notion·
6 min read

Based on Notion's video on YouTube. If you like this content, support the original creators by watching, liking and subscribing to their content.

TL;DR

Stytch was founded after its leaders couldn’t find an authentication vendor that was both API-first and genuinely developer-friendly for secure, customizable integration.

Briefing

Stytch’s co-founder and CTO Julianna Lamb traces the company’s rise to a simple but high-stakes premise: authentication and fraud prevention only work if developers can integrate them reliably, quickly, and with confidence. The idea took shape while she and co-founder Reid Hoffman worked on credential-stuffing and account-takeover problems at Plaid and VGS, where they built authentication and multifactor defenses in-house (including SMS and email one-time passcodes). When they searched for an “authentication vendor” that was truly developer-friendly—API-first, plug-and-play, and flexible enough to customize—they couldn’t find one that matched their needs, so they decided to build it themselves.

The path from concept to product accelerated during early 2020, when COVID created time for intensive customer discovery. After raising a seed round in June 2020, the team prioritized hiring before building out a full product suite. Lamb credits that choice to reliability: for “critical infrastructure,” the quality of the developer experience matters as much as the underlying security. Stytch’s early beta launched roughly four months after the first engineer joined, centered on email “magic links” plus a self-serve dashboard where developers could obtain API keys and start integrating without talking to anyone. Word of mouth drove early signups, and some customers went live without even direct conversations—an outcome Lamb describes as rare and revealing, because it validated demand in the wild.

Getting to that first public version required disciplined iteration. The team repeatedly watched real developers integrate the product, then used what broke—errors, missing documentation, unclear failure modes—to improve the experience before scaling. Lamb also emphasizes how the company’s early roadmap thinking was designed to make future authentication products easier to build, not just to ship one feature set.

As Stytch grew, Lamb’s role evolved from hands-on engineering and code reviews to managing managers and shaping product and engineering strategy alongside Reid. She describes a series of inflection points: moving from coding to leading a small team, then hiring engineering managers, then bringing in PMs, and eventually working with a head of engineering and a head of product. Her advice for CTOs is blunt: avoid trying to straddle both deep technical leadership and people leadership at once—commit to the path that fits.

On hiring, Lamb says Stytch invested heavily upfront, including a two-month sprint to find strong frontend and infrastructure talent despite her own limited background in those areas. The team used take-home exercises to evaluate code quality and shipped a culture of fast iteration—citing an average time to production of 13 minutes—powered by tooling, monitoring, and a remote developer environment. Continuous deploys for its core API service arrived later, enabled by testing infrastructure.

Finally, Lamb links go-to-market success to tight product-engineering feedback loops. PMs and solutions engineers join customer calls early to capture pain points directly, while Gong recordings reduce the friction of hearing customer voice at scale. Stytch also treats marketing as two pillars: credibility-building engineering content and higher-intent SEO aimed at engineers. Open source matters to the company because it both leverages community work and gives back solutions built from recurring internal pain.

Cornell Notes

Stytch’s co-founder and CTO Julianna Lamb says the company formed because existing authentication vendors weren’t developer-friendly enough for secure, plug-and-play integration. After seed funding in June 2020, Stytch prioritized hiring early and launched a self-serve beta (email magic links plus a dashboard for API keys) about four months after the first engineer joined. Early adoption came largely through word of mouth, including cases where developers went live without direct conversations—evidence the product fit real needs. Lamb credits product-market momentum to watching developers integrate, then fixing integration pain (errors, docs, and failure modes) before scaling. As the company grew, her role shifted from coding to leading managers and partnering with Reid on product and engineering strategy, while go-to-market stayed closely tied to customer calls and developer-focused marketing.

Why did Stytch’s founders decide to build authentication in-house instead of buying from a vendor?

Lamb describes working on fraud and authentication problems—especially credential stuffing and account takeover—at Plaid and VGS. After building authentication internally (including SMS and email one-time passcodes), she and co-founder Reid looked for an authentication vendor that was “developer friendly” and “plug and play,” with an API-first approach that could be dropped into a product and customized as needed. They couldn’t find a solution that matched those requirements, so they built Stytch as a Stripe-like layer for authentication.

What did Stytch’s early beta product look like, and how did it support self-serve adoption?

After seed funding, Stytch focused on a self-serve experience so developers could log into a dashboard, retrieve API keys, and try the product without talking to anyone. The initial beta launch centered on email magic links plus the self-serve dashboard. Lamb notes the beta launched about four months after the first engineer joined, and early customers often signed up via word of mouth on channels like Twitter and LinkedIn.

How did Stytch improve the integration experience before and after the first launch?

Once the team had something developers could integrate, Lamb says they ran Zoom sessions where engineers (including herself and engineers) watched developers implement the product. They tracked pain points such as integration errors, unclear error messages, and documentation gaps. Those observations fed into improvements so the public launch wasn’t just “bare bones,” but a meaningfully better integration path than what existed before.

What hiring strategy helped Stytch move quickly without sacrificing quality?

Lamb says Stytch hired a small initial team immediately after raising the seed round—four engineers at the start (frontend, backend, full-stack, and platform/infra). Because she had little frontend and infra experience, she treated evaluating those skill sets as the hardest part of hiring. The team used take-home exercises to review code and the finished product, spending roughly two months interviewing—an investment Lamb calls worthwhile for critical infrastructure reliability.

How did Stytch build a culture that ships fast, and what concrete systems supported that?

Lamb links speed to developer experience and tooling/monitoring. Early investments included distributed tracing via Honeycomb (implemented even before live traffic existed) and a remote developer environment that synced code with the full stack so changes could be tested instantly. Later, Stytch implemented continuous deploys for its core API service using a merge queue that automatically deploys after PR merge—made possible by strong testing infrastructure.

How did go-to-market stay aligned with product development as Stytch scaled?

Lamb emphasizes early and ongoing customer contact between product and engineering. PMs join customer calls frequently, and solutions engineers translate needs, but PMs still hear pain points firsthand. Stytch also uses Gong to record and share selected customer calls with the EPD teams, lowering the barrier to hearing customer voice. On the sales side, Lamb distinguishes roles: authentication is high-trust, so AEs need relationship and urgency skills, while SEs provide technical specialization.

Review Questions

  1. What specific developer-experience mechanisms (product features, dashboard access, error handling, documentation practices) helped Stytch validate demand during its first public beta?
  2. How did Lamb’s view of CTO evolution lead to her advice about avoiding “straddling both worlds,” and what role changes did she describe as Stytch scaled?
  3. Which internal tooling investments (e.g., Honeycomb, remote dev environment, continuous deploys/merge queue) most directly supported Stytch’s reported 13-minute average time to production?

Key Points

  1. 1

    Stytch was founded after its leaders couldn’t find an authentication vendor that was both API-first and genuinely developer-friendly for secure, customizable integration.

  2. 2

    Seed funding in June 2020 was followed by early hiring, because reliability of the developer experience is critical for authentication infrastructure.

  3. 3

    The first beta focused on email magic links and a self-serve dashboard that let developers get API keys and integrate without direct sales or support.

  4. 4

    Integration quality improved through repeated developer walkthroughs that surfaced concrete issues like integration errors, weak error messages, and documentation gaps.

  5. 5

    Lamb’s hiring approach combined structured recruiting with take-home code exercises to evaluate frontend and infrastructure quality despite her own limited expertise in those areas.

  6. 6

    Stytch’s fast shipping culture relied on developer experience tooling (Honeycomb tracing, remote dev environments) and later continuous deploys for its core API service.

  7. 7

    Go-to-market alignment came from frequent product-engineering participation in customer calls, supported by Gong recordings and a role split between relationship-driven AEs and technical SEs.

Highlights

Stytch’s early beta launched with email magic links plus a self-serve dashboard for API keys—designed so developers could integrate without talking to anyone.
Lamb describes watching developers integrate on Zoom to diagnose what broke: error messages, documentation gaps, and unclear failure modes.
Stytch’s average time to production was 13 minutes, driven by early investments in observability (Honeycomb) and a remote developer environment.
Lamb’s CTO advice: avoid trying to straddle both technical leadership and people leadership; commit to the path that fits best.
Customer voice scaled through Gong recordings and a curated library of calls for solutions engineering and EPD teams to listen to.

Topics

Mentioned