CHAPTERS
- 0:05 – 0:55
Trigger.dev today: SDK to run reliable AI agents inside your product
Matt explains Trigger.dev as an SDK + platform that lets teams add AI agents to existing products, with reliable execution handled for them. The emphasis is on long-running, dependable agent workflows rather than simple scripts.
- •Add AI agents to an existing app via an SDK
- •Trigger runs/executes agents reliably on its infrastructure
- •Focus on long-running workflows and operational reliability
- 0:55 – 1:32
Origins in YC: “Zapier for developers” and the async jobs framing
The team recounts the early positioning during YC W23-era: a developer-friendly alternative to Zapier plus an async background jobs framework. A strong Hacker News launch helped them stand out among similar “Zapier for devs” attempts.
- •Early pitch: “Zapier for developers”
- •Initial product: async background jobs framework (early in the batch)
- •Strong Hacker News reception validated interest
- 1:32 – 4:14
Design as a differentiator: code-first UX and the first 5 seconds
They attribute early traction to care in both visual design and developer experience design. They optimized the landing page to show code immediately, reflecting how developers evaluate tools quickly.
- •Design = developer experience, not just visuals
- •Landing page optimized to show code upfront
- •They designed the code developers would write before designing everything else
- •Goal: make it hard for developers to fail using the SDK
- 4:14 – 5:54
First pivot: from internal “back office” automation to product-embedded workflows
They learned that the best use cases weren’t internal ops automations, but product features delivered to end users. Version two refocused Trigger on embedding async tasks directly into customer products.
- •Early customers used it for internal tooling (sales/marketing/biz ops)
- •Best use cases were embedded in the product’s user-facing flow
- •Shift: “value to users” vs “value to your team”
- •Examples: document processing, video encoding, background product tasks
- 5:54 – 6:31
Serverless created the gap: long-running tasks, retries, and reliability primitives
The conversation frames Trigger’s opportunity as a consequence of serverless trends: great for short request/response but weak for long-running work. Trigger aimed to provide queues, retries, idempotency, and durability as a developer-friendly abstraction.
- •Serverless made long-running background work harder
- •Need for reliability: queues, retries, idempotency
- •Trigger positioned as the missing layer for durable async execution
- 6:31 – 7:16
Why v2 wasn’t PMF: demand existed, but the product didn’t match the job
They describe v2 adoption as ‘okay’ but not product-market fit, in part because developers still had to manage messy execution themselves. Two changes drove the next shift: AI’s rise and their decision to run customer code directly.
- •v2 growth existed but wasn’t PMF
- •Product didn’t solve the problem cleanly enough
- •AI workloads made async tasks far more valuable
- •Decision: move from SDK-only to executing user code
- 7:16 – 9:31
Version 3 breakthrough: Trigger executes the code (and PMF arrives fast)
In summer 2024 they launched v3 where Trigger provides SDK + platform + infrastructure, and growth accelerated. They discovered many users already assumed Trigger was executing the jobs, making the transition natural.
- •v3 launched June/Summer 2024
- •Trigger now executes jobs on its own infrastructure
- •Customers already believed Trigger executed the code (poll: ~60%)
- •PMF: strong revenue growth, later paid plans (+~30% MoM for a long period)
- 9:31 – 10:43
Open source + cloud business model: permissive Apache 2 with managed compute
They explain why monetization is straightforward despite being open source: the core value is managed compute and operational simplicity. They keep most functionality open while retaining the hard-to-scale orchestration layer as the main cloud advantage.
- •Apache 2, highly permissive licensing
- •Most features remain open source
- •Cloud offering monetizes managed compute/infrastructure
- •Kubernetes orchestration layer is the hardest part to replicate/scale
- 10:43 – 13:36
Customer case study: Icon.com and the anatomy of a successful agent workflow
Icon.com uses Trigger to process user-uploaded assets and generate many video ads, with real-time progress and feedback loops. Matt breaks down agent building into two phases—context preparation and action/generation—and highlights human-in-the-loop pausing.
- •Icon workflow: ingest assets → classify/process → generate many ads → publish
- •Two-part agent model: context gathering vs generation/action phase
- •Real-time feedback during long-running workflows
- •Human-in-the-loop is critical; workflows can pause for feedback and resume
- 13:36 – 14:58
Trigger is now mostly agent loops: 90%+ of usage and more customer examples
They report that over 90% of Trigger’s usage is now agent workflows. Additional examples include Magic School (teacher/student tools) and Scrapybara (coding agent that modifies repos and ships commits).
- •Agent workflows account for 90%+ of usage
- •Magic School: agent-driven lesson planning, marking, student support
- •Scrapybara: coding agent runs evaluation loops and commits to GitHub
- •Trigger handles full agent execution for these products
- 14:58 – 17:14
Full-machine power + pause/resume primitives: toward checkpoint/restore computing
Eric describes how developers can access full machine capabilities (shell, Python tools, FFmpeg, Chromium/Puppeteer) through a TypeScript-first interface. They see programmatic snapshot/restore (checkpointing) as a foundational primitive for future computing.
- •TypeScript-first framework, but full machine image customization
- •Run heavy tools: FFmpeg, Puppeteer/Chromium, ‘computer use’ automation
- •Key primitive: pause/resume with full state preserved
- •Vision: democratize low-level checkpoint/restore scheduling in the cloud
- 17:14 – 19:51
Vibe coders vs traditional devs: the gap collapsed as models and docs improved
They observed a clear split earlier—novices struggled and used the product poorly—but that distinction has faded. Better models (Opus 4.5) plus Trigger’s LLM-friendly docs and MCP server improved outcomes and reduced support burden per unit growth.
- •Earlier: two support profiles (novice ‘vibe coders’ vs advanced devs)
- •Now: hard to distinguish; agents/tools made novices more effective
- •Trigger invested in LLM-friendly docs, skills, and an MCP server
- •Support growth lags behind customer/revenue growth as self-serve improves
- 19:51 – 23:27
Open source as agent marketing: LLMs read the repo, find bugs, and drive adoption
They explain that open source is a major advantage because the codebase becomes training/ground truth for both humans and LLMs. Customers and agents can inspect tests, diagnose issues, and even generate PR-ready fixes—turning the LLM into an additional ‘user.’
- •Customers use the repo as source-of-truth documentation
- •LLMs can read tests and identify precise bugs
- •Workflow: customer/Claude finds bug → generates write-up → PR can be produced quickly
- •Marketing to agents emerges: bigger footprint on the internet helps recommendation
- 23:27 – 27:41
Hiring after Opus 4.5: smaller engineering plans, more leverage per person
Post-Series A, their hiring plan changed materially due to major productivity gains from better coding agents and planning tools. They still hire, but less aggressively, and shift focus toward marketing/devrel/content to teach agent-building patterns.
- •Series A in November; by early 2026 hiring plans scaled back
- •Per-engineer productivity up ~5–10x with newer tools
- •Still hiring engineers, but selectively
- •New roles: developer relations and content engineer; publish broader agent-building content
- 27:41 – 31:21
Shipping high-quality code with agents: design systems, tests, and stronger review
They address the ‘AI slop’ critique by emphasizing constraints and verification: strong reusable UI components, more testing, and better code review tooling. Agents are used not just to write code, but to do staff-level work like benchmarking and preflight analysis.
- •Quality comes from good components/design system, not AI-generated UI each time
- •Bottleneck shifts to review, UX, and ‘de-slopping’
- •Heavier investment in tests so agents can verify success
- •Use agents for benchmarking, analysis, and safety checks—not only code generation
- 31:21 – 33:52
Advice to new founders: ship early, stay close to customers, know when to persist
They close with classic YC-aligned advice: shipping early is the fastest learning loop, and real signals come post-launch. Matt adds that persistence vs pivoting is hard; their conviction came from personal pain and continuous customer proximity.
- •Ship early to learn what matters and whether it’s mission-critical
- •Reality checks come from paying users, bugs, and operational constraints
- •Persistence is hard to time; they endured ~2 years before PMF
- •Stay extremely close to customers; daily feedback reveals direction
