Y CombinatorEmergent: How Six Months of Tinkering Led To A $100M ARR Company
CHAPTERS
- 0:00 – 0:56
Mission: Democratize software creation beyond programmers
Mukund opens with a macro view: most economic gains over recent decades have come from software companies. He frames Emergent’s mission as giving the power to build software to the billions of people whose ideas die without technical access.
- •Software drives outsized global economic gains compared to non-software sectors
- •Vision: bring the ability to create software to “almost everybody”
- •Ideas often fail due to lack of technical access, not lack of demand
- •Sets the north star: democratization of coding as leverage for the world
- 0:56 – 2:54
What Emergent is: chat-to-shippable apps with full ops handled
Emergent is described as a platform where non-programmers can build real, monetizable software by chatting with an AI agent. The product includes hosting, deployment, and maintenance—aiming for end-to-end shipping rather than prototyping.
- •No-code/low-code via natural language: “as easy as chatting”
- •Focus on shippable apps users can monetize (not just demos)
- •Platform handles hosting, deployment, and maintenance
- •Origin as a research effort building coding agents
- 2:54 – 3:44
Hypergrowth metrics: 9 months to massive scale
Jared emphasizes how young the company is, and Mukund shares rapid traction figures. He attributes growth to intense latent demand from entrepreneurs and builders without access to engineering teams.
- •Launched ~9 months prior to the talk
- •~8.5M users and 10M+ apps built (as stated)
- •Crossed $100M+ annualized run rate
- •Core user demand: entrepreneurs without tech teams now able to ship
- 3:44 – 4:45
Why build global from India: users in 190 countries, revenue abroad
Mukund explains his long-standing question—why India hasn’t produced Google/Facebook-scale global tech—and how Emergent is designed to be global-first. He notes that most revenue comes from the US/Europe, with India a minority share.
- •Users span ~190 countries
- •Motivation rooted in observing Indian leadership abroad but few global-first Indian companies
- •Revenue primarily from US and Europe; India ~10% (as stated)
- •Personal commitment to building a global tech company from India
- 4:45 – 6:50
Dunzo origin: doing things that don’t scale to learn logistics reality
Mukund recounts Dunzo’s early days as a WhatsApp concierge and how the hard part was last-mile execution. He shares hands-on tactics—literally delivering orders himself—to stay close to customers and iterate on real pain.
- •Dunzo began as simple concierge ordering; execution was the moat
- •Many competitors existed; differentiation came from operational excellence
- •Founder did deliveries personally to understand the workflow
- •YC principle validated: doing things that don’t scale builds deep customer insight
- 6:50 – 10:35
Five startups and early career: from PhD dropout to Google to founder lessons
Mukund walks through his background: inspiration from Steve Jobs, a PhD start in the US, and joining Google’s search ranking team. He then describes multiple startup attempts, pivots, and shutdowns—emphasizing intuition and personal pain as idea sources.
- •Inspired early by product creation (e.g., first iPhone launch era)
- •Dropped PhD after realizing Google was ahead on his research area
- •Worked on Google search ranking; pushed for ML adoption early
- •Multiple startups before Dunzo; learned hard truths about passion, focus, and geography
- •Recurring lesson: trust intuition and start from personal pain points
- 10:35 – 13:21
Scaling Dunzo: customer obsession, and the cost of losing focus
Mukund shares Dunzo scale metrics and what he’d replicate or change. He highlights a culture of extreme customer care and argues that lack of focus—pursuing many models instead of doubling down—contributed to later challenges.
- •Scale referenced: 10M monthly orders, large rider/store network
- •Deep customer obsession as a cultural operating system
- •“Solve the hard problem” as a repeatable pattern
- •Key regret/lesson: focus—doubling down on what worked vs. spreading across many bets
- 13:21 – 15:43
Leaving Dunzo: depression, then six months of pure tinkering with AI
After leaving in 2023, Mukund describes a difficult emotional period followed by a rebuilding phase driven by curiosity. The explosion of LLM capabilities became his escape—10–12 hour days experimenting with models—leading directly to insights behind Emergent.
- •Exit period described as emotionally difficult and reflective
- •AI wave (ChatGPT, GPT-4 era) enabled rapid experimentation
- •Tinkering without a business objective produced key insights
- •Early prototypes (e.g., Mac assistant) clarified that coding would be disrupted quickly
- 15:43 – 18:07
Tinkering + “living at the edge”: betting on what will soon be possible
Jared introduces YC’s “living at the edge” concept: building where capabilities are just barely emerging. Mukund explains how VCs rejected the idea of automating software engineering, but the team saw “sparks” and extrapolated rapid model progress.
- •Many investors dismissed “automate SWE” as too early
- •Founder conviction came from hands-on experimentation, not consensus
- •Strategy: design for exponential model improvement
- •Living at the edge reveals future markets before they’re obvious
- 18:07 – 19:07
Emergent’s technical foundation: multi-agent orchestration + self-improving memory
Mukund outlines Emergent as an autonomous, multi-agent system rather than a copilot. Specialized agents (design, testing, etc.) coordinate via a memory system that learns from every app built, improving the platform over time.
- •Multi-agent architecture with task-specialized agents (design, testing, etc.)
- •Central memory system that extracts learnings from every build
- •Continuous improvement loop: each app built makes the agents better
- •Heavy investment in proprietary infrastructure and data collection (RL, some fine-tuning)
- 19:07 – 20:48
Hard infra problems: containers, state snapshots, parallelism, and constant rewrites
Building autonomous coding required infrastructure that didn’t exist off-the-shelf. Mukund describes creating container/state snapshotting to allow parallel agents, and the need to rewrite systems repeatedly as new model classes change what’s possible.
- •Invented/implemented container and state preservation (disk + memory snapshots)
- •Parallel agents “swarm” to complete tasks faster and more reliably
- •Operating principle: new model releases force rethinking architecture
- •Rewrote core system multiple times in ~9 months to match capability shifts
- •Chose to skip short-lived problems (e.g., JSON reliability) expecting model improvements
- 20:48 – 22:49
Beating SWE-bench: the benchmark that became the company’s backbone
Mukund shares how, during YC, the team struggled to settle on a product and used SWE-bench as a focusing mechanism. Becoming #1 on the benchmark created the technical core—world-class coding agents and key innovations—later embedded into Emergent.
- •Early YC period involved rapid weekly pivots and team frustration
- •SWE-bench chosen as a forcing function and progress metric
- •Achieved world #1 with a small team, creating credibility and capability
- •Benchmark work yielded innovations: memory, agent communication, parallelized test-time compute
- •Lesson: attach to measurable metrics to drive focus and iteration speed
- 22:49 – 25:32
Second-mover advantage: shipping real software, plus an engineered growth loop
Mukund explains why entering a crowded AI website/app builder space still worked: competitors produced front-end demos, while Emergent focused on full-stack, working software that ‘finishes.’ He also describes treating growth like a math problem and scaling via influencer distribution once product quality was strong.
- •Competitor gap: demo/prototype focus vs. end-to-end working software
- •Differentiation: real backends, databases, and “finish line” execution
- •Product advantage validated through internal comparisons on real prompts
- •GTM approached quantitatively: impressions → clicks → users
- •Influencer-led distribution used to rapidly reach global users
- 25:32 – 29:04
Building global from Bangalore: team strategy, hiring, and founder advice
The company is primarily based in Bangalore with a small SF presence, reflecting a global-first approach from India. Mukund closes with takeaways: global vs local is similar effort, trust founder intuition, and think far more ambitiously in the AI era.
- •~95% of team in Bangalore; small office/team in San Francisco
- •Hiring emphasis: learning slope and genuine excitement for AI problem-solving
- •View: building for India vs global requires similar effort—so start global
- •Founder principle: trust your intuition amid abundant external advice
- •AI era favors ceiling-thinking—10x/100x ambition and harder problems
