Skip to content
ClaudeClaude

How Emergent is making app building more accessible with Claude

Emergent reached $100M ARR in eight months, with 70–80% of users having never written a line of code. In this conversation, Co-founder and CEO Mukund Jha sits down with Anthropic's Carly Ryan to talk about the technical decisions behind building on Claude and how Emergent thinks about durability in a category moving this fast. Read the full story: claude.com/customers/emergent

Mukund JhaguestCarly Ryanhost
May 13, 202616mWatch on YouTube ↗

CHAPTERS

  1. 0:00 – 0:21

    Emergent’s mission: AI-built software for the “million niches” of small business

    Mukund frames Emergent’s core thesis: small businesses drive most global employment and a huge share of GDP, yet lack bespoke software because traditional SaaS can’t economically serve endless niches. AI changes that equation by enabling highly customized software at near-zero marginal cost.

    • Small businesses represent ~70% of employment and ~50% of global GDP
    • Traditional SaaS economics push vendors upmarket, leaving niches underserved
    • AI enables serving many niches with minimal marginal cost
    • Emergent’s goal is to empower small business operators with software built from natural language
  2. 0:21 – 1:22

    From sibling founders to YC: the original bet on automating software testing

    Mukund recounts how he and his twin brother started programming young and entered YC with a focus on automating software testing. Experience running a large engineering org made him see testing as a key bottleneck to shipping faster.

    • Twin founders with an early programming background
    • Prior company experience highlighted testing as a major delivery bottleneck
    • Initial product direction centered on automated testing across web/mobile
    • Early YC insight: solving testing could unlock broader automation
  3. 1:22 – 1:56

    Pivot to general coding agents: verification loops, multi-agent systems, and long-running autonomy

    While building automated testing, the team realized they needed deeper agent infrastructure (containers, coding agents) and that verification enables agents to run longer. They began operating like an applied research lab, productionizing multi-agent systems and building mechanisms like test-time compute and scalable memory.

    • Testing work revealed the need to build container tech and coding agents
    • Key insight: strong verification loops enable long-running agents
    • Early focus on multi-agent coordination and agent-to-agent communication
    • Built techniques such as test-time compute and memory scaling for agents
  4. 1:56 – 2:14

    Enterprise wasn’t the wedge: internal usage revealed the real opportunity—democratization

    Emergent initially tried selling into enterprise but found adoption slow. Meanwhile, internal usage showed non-technical teammates benefiting heavily, leading to the realization that democratizing software building for everyone was the bigger opportunity.

    • Early enterprise customer validated interest but sales/adoption were slow
    • Internal agents were used heavily for building company needs
    • Non-technical users found surprising leverage from agents
    • Strategic shift toward broad accessibility and user success
  5. 2:14 – 3:10

    Beyond prototypes: production-ready app building with testing, security, deployment, and reviews

    Mukund explains why Emergent approached text-to-app as a production engineering problem, not a demo generator. The product emphasized end-to-end reliability—testing, linting, deployment, security, and code review—because users were serious builders seeking economic value.

    • Goal is durable, business-critical software—not just front-end demos
    • Automates testing, linting, deployment, security, and code reviews
    • User base includes small businesses and entrepreneurs focused on ROI
    • Outcome quality is prioritized over flashy prototypes
  6. 3:10 – 5:20

    Why Claude (Sonnet/Opus): instruction-following, coding strength, and outcome-first quality

    Mukund describes choosing Claude early—especially Sonnet—because its instruction following enabled the vision of long-running agents. Emergent’s users compare it to a dev shop, so the company optimizes for correctness and outcomes, leaning on Opus as a high-quality workhorse.

    • Build for where models will be in ~6 months, not just today’s capabilities
    • Sonnet enabled the long-running agent vision via strong instruction following
    • Users compare Emergent to a dev shop; outcomes matter more than speed
    • Opus chosen for high-quality reasoning and instruction adherence
  7. 5:20 – 6:28

    Owning the entire stack: containers, harness quality, and tight feedback loops

    The team learned that automated software engineering requires controlling every layer, co-building infrastructure and agents together. They built container tech on Kubernetes (snapshotting/state) to run parallel agents and emphasized “harness quality” as a key determinant of agent performance.

    • Owning the full stack prevents last-mile failures
    • Built custom container/snapshotting to preserve state and parallelize agents
    • Harness quality is central: the agent is effectively the product
    • Feedback loops between infra and agents improve reliability and iteration
  8. 6:28 – 7:19

    Production data flywheel: deep logs, long-term memory across apps, and faster learning

    Emergent feeds production issues back into development to capture errors that only appear with real users. A long-term memory system lets agents learn across all apps, so new errors and library changes are handled with fewer tokens and higher accuracy over time.

    • Many failures appear only in production, not dev; Emergent captures them
    • Deep logging enables compounding improvements from real-world usage
    • Long-term memory learns across apps, not just within a single session
    • Faster future fixes: fewer tokens, more accuracy after first encounter
  9. 7:19 – 9:01

    Model selection when users can’t debug: prioritize reliability, not latency or cost

    Because many users are non-technical, Emergent shoulders the debugging burden and measures success by deployability. Mukund explains why they choose frontier reasoning models: users aren’t cost- or latency-sensitive compared to a multi-month dev shop engagement, but they demand high success rates.

    • Non-technical users increase the platform’s responsibility for success
    • Deployment rate improved from ~84% to ~98% via tighter loops
    • Users benchmark against expensive dev shops, reducing cost sensitivity
    • Long-horizon workflows amplify small errors, making instruction-following critical
  10. 9:01 – 10:58

    What’s hard to replicate: customer focus, proprietary data/infra, vertical stack, and full lifecycle delivery

    Mukund argues the market is expanding fast, so Emergent focuses on serving its target customer deeply rather than fixating on competitors. Their moat combines high-quality agent harnessing, proprietary production data, focus on a single stack, and delivering the full lifecycle (deployment, maintenance, security).

    • Market growth is rapid; differentiation comes from execution and customer fit
    • Customers care about real integrations: payments, auth, file handling, scaling
    • Moat components: agent/harness quality + proprietary data + vertical stack focus
    • Code generation is ~20%; the other ~80% is deployment, maintenance, and security
  11. 10:58 – 13:32

    Multi-agent workflow for quality: refactoring, pre/post-deploy checks, and security scanning

    Carly highlights a key product pattern: one agent builds, then others clean up and harden the codebase. Mukund details refactoring agents and pre/post-deployment agents that catch security flaws and secret/key leaks to keep apps maintainable and trustworthy.

    • Separate agents handle build vs. cleanup/refactoring for maintainability
    • Pre-deployment and post-deployment agents run security checks
    • Focus on preventing key/secret leakage and other common vulnerabilities
    • Outcome-first design shapes the multi-agent pipeline
  12. 13:32 – 15:26

    Who builds with Emergent: domain experts and a standout user story (EquiMind)

    Emergent expected semi-technical users but found strong adoption among business operators and domain experts who can now express needs directly. Mukund shares the EquiMind story: a clinical psychologist/equestrian coach built and shipped an app after dev shop attempts failed, illustrating new access to software creation.

    • Primary users: domain experts and operators who’ve never coded
    • Natural-language specs reduce the communication gap with developers
    • Global reach: users in ~190 countries and millions of users reported
    • Case study: EquiMind built and shipped to the App Store, serving real users
  13. 15:26 – 16:38

    What’s next: longer-horizon autonomy and ‘Wingman’ to automate business operations

    Mukund describes rapid internal rewrites driven by new model capabilities and the need to reimagine systems with each frontier release. Looking ahead, Emergent plans a new agent and a product called Wingman to automate end-to-end business processes—finances, operations, sales, and marketing—moving from app building to autonomous business execution.

    • Team rewrote systems multiple times to adapt to new model capabilities
    • Opus-class models enable longer-horizon, coordinated multi-agent work
    • New agent planned, positioned as a big step forward
    • Wingman aims to automate core business functions beyond software creation

Get more out of YouTube videos.

High quality summaries for YouTube videos. Accurate transcripts to search & find moments. Powered by ChatGPT & Claude AI.