CHAPTERS
Trigger.dev today: SDK + platform to run reliable AI agents in your product
Matt and Eric explain Trigger.dev’s current purpose: an SDK that lets product teams add AI agents and long-running workflows into their apps, while Trigger runs them reliably. The emphasis is on execution, reliability, and not making developers manage infrastructure for these agent tasks.
- •TypeScript-first SDK for building agents and workflows
- •Trigger runs/executes agents reliably on its infrastructure
- •Designed for long-running, asynchronous, failure-prone work
- •Focus on developer experience and easy-to-succeed primitives
v1 in YC: “Zapier for developers” and the early developer-design philosophy
They revisit the YC-era positioning: a developer-first automation tool (the “Zapier for devs” meme) that resonated on Hacker News. They credit strong design and “code-first” communication—showing code immediately—as a major driver of adoption and interest.
- •Pitched as “Zapier for developers” and launched early in the batch
- •Strong Hacker News launch helped validate interest
- •Design includes DX: make it hard for developers to fail
- •Landing page and code snippet as the primary sales/education surface
From back-office automations to embedding workflows into customer products
Early users tended to treat Trigger as an internal automation layer (sales/marketing/biz ops), similar to Zapier. The team learned the highest-value use cases came from customers embedding background workflows directly into their product’s user experience.
- •Back-office automations: GitHub ops, marketing, sales workflows
- •Shift toward “hot path” product features for end users
- •Async background work like document processing or video encoding
- •Need for queues, retries, idempotency, and reliability as core value
Serverless created a gap: long-running work became painful
They connect the product’s direction to broader infrastructure trends: serverless is great for short request/response but poor for long-running tasks. Trigger’s core promise became filling that gap with durable execution primitives developers could rely on.
- •Serverless excels at short-lived tasks, struggles with long-running jobs
- •Durable workflows require retries, state, and orchestration
- •Trigger positioned as the missing layer for modern app backends
- •Infrastructure abstraction is part of the product’s appeal
The first major pivot: v2 adoption was “okay,” but not PMF
Version two improved the embedded use case, but they still didn’t feel strong product-market fit. They saw real demand but concluded the product didn’t match the problem well enough, in part because developers still had to write messy code and manage too much themselves.
- •Growth existed but wasn’t convincing PMF
- •Demand was real; product fit and implementation weren’t there
- •Customer friction came from complexity and messy integration
- •Realization that execution model needed to change
v3 breakthrough: Trigger executes the code (and customers expected that anyway)
In summer 2024 they shipped v3, moving from “SDK only” to SDK + platform + infrastructure that actually runs the tasks. A customer poll showed many users already assumed Trigger executed the jobs—making the shift both logical and aligned with expectations.
- •v3 launched June/summer 2024: Trigger runs the compute
- •Poll: ~60% of customers believed Trigger already executed the code
- •Some users preferred the old model, but most wanted managed execution
- •This change unlocked the “long-running, reliable, managed” promise
Hitting product-market fit: rapid revenue growth and charging after beta
After v3, they saw immediate traction and sustained strong growth. They started with a free beta, then began charging a couple months later, describing consistent ~30%+ month-over-month revenue growth for an extended period.
- •PMF felt “pretty much straight away” after v3
- •Beta first, monetization shortly after
- •Sustained strong MoM growth (~30%+)
- •Reliability + managed execution became a paid, repeatable value prop
Open source strategy: permissive Apache 2 plus a clear cloud value line
They describe how open source fits the business: most teams prefer the hosted cloud offering because it removes infrastructure burden. Almost all functionality is open, while the hardest-to-operate scaling layer (Kubernetes orchestration/management) is the main differentiator in the managed product.
- •Apache 2.0 permissive licensing
- •Cloud offering monetizes managed compute and operations
- •Most features are open source; scaling/ops layer is the key boundary
- •Helm chart exists, but running/scaling it well is difficult
Customer stories and what “agent workflows” look like in practice
They share concrete examples that illustrate why durable execution matters for AI. Use cases include generating video ads (Icon.com), education workflows for teachers/students (Magic School), and coding agents that pull repos, run tools, and commit changes (Scrapybara).
- •Icon.com: asset ingestion + classification + video generation at scale
- •Magic School: teacher/student workflows powered by background agents
- •Scrapybara: coding agent runs toolchains, modifies code, pushes commits
- •Trigger supports shell tools, FFmpeg, Puppeteer/Chromium, and more
Why agents need “pause/resume”: checkpointing compute for human-in-the-loop loops
A major theme is the primitive of pausing, waiting for feedback, then resuming with full state intact. They argue the future is programmatic snapshot/restore of CPU/memory/filesystem state, avoiding complex manual state rehydration and enabling human/agent-in-the-loop workflows.
- •Two parts of agents: context buildup + action/generation phase
- •Human-in-the-loop is critical; workflows pause to request feedback
- •Pause compute until input arrives, then resume the same state
- •Vision: checkpoint/restore as a foundational computing primitive
“Vibe coders” vs traditional devs: the gap narrows as models and docs improve
They observed a sharp split earlier—novices struggled and support signals were obvious. With better models (Opus 4.5) and Trigger becoming more LLM-friendly (better docs, MCP server, agent-oriented materials), usage patterns have converged and the distinction is less visible.
- •Earlier: two support tracks—true novices vs advanced devs
- •Now: better coding agents reduce misuse and confusion
- •Trigger invested in LLM-friendly docs and an MCP server
- •Improved models make onboarding and implementation more consistent
Open source as “agent marketing”: LLMs read repos, tests, and even propose fixes
They frame LLMs as a second user persona: not just humans, but agents that choose tools. Open source increases their “footprint” on the internet, letting models inspect real code/tests and enabling customers to arrive with precise bug reports—or even patches—generated by Claude.
- •LLMs can query the repo as source-of-truth documentation
- •Customers bring higher-quality bug reports (sometimes with root cause)
- •Team can use agents to draft fixes and ship PRs quickly
- •Future direction: agent-driven onboarding (account creation is the main hurdle)
Hiring and shipping with agents: fewer engineers, higher leverage, new evaluation methods
Post–Opus 4.5, they revised hiring expectations: productivity per engineer is far higher, so they’ll hire more selectively. They emphasize hiring for ability to leverage AI tools and use a paid “trial day” to observe real-world output rather than LeetCode-style interviewing.
- •Hiring plan changed after Series A due to 5–10x productivity gains
- •Still hiring (plus dev rel/content), but less aggressively
- •Interview includes paid trial day; strong AI-tool usage is required
- •Shift from theoretical puzzles to practical high-quality shipping
Maintaining quality (avoiding “slop”): design systems, tests, and agent-assisted review
They address the critique that agents generate low-quality code by describing guardrails: strong reusable UI components, a design system, and more tests—especially backend tests that verify success criteria for agents. Code review becomes the bottleneck, with specialized review tools and founders/design leadership ensuring UX and maintainability stay high.
- •Use high-quality components and a design system instead of AI-generated UI from scratch
- •Add extensive tests so agents can verify correctness and completion
- •Use agent-assisted code review tools; review/UX is the main bottleneck
- •Use agents beyond code-writing: benchmarking, analysis, production safety checks
Founder advice: ship early, stay close to customers, and know when to persist vs pivot
They close with YC-aligned guidance: shipping quickly is the fastest way to learn what matters and whether the problem is real. Matt adds the harder meta-skill—deciding when to keep going without PMF—grounded in personal pain, persistent customer signals, and daily customer proximity.
- •Ship early to learn constraints, urgency, and real-world failure modes
- •Customer feedback and payment are stronger signals than speculation
- •Persistence is hard to judge; personal pain helped them stay committed
- •Talk to customers daily to avoid building in a vacuum
