From Zapier for Devs to Powering 90% AI Agents

Trigger.dev evolved from a "Zapier for developers" concept into infrastructure for embedding AI agents and long-running workflows directly inside software products. The core thesis is that developers want a simple SDK while outsourcing execution, reliability, retries, queues, and long-running task management. According to the founders, product-market fit emerged only after they shifted from helping developers define async work to actually executing that work on Trigger.dev’s infrastructure, a change that aligned with rising AI demand. The interview also signals a broader view of software development: AI changes both what products need operationally and how engineering teams should work, hire, review code, and measure productivity.

Key insights

1. The winning wedge was not automation for internal teams, but infrastructure embedded in customer-facing products: Early use cases resembled developer-oriented Zapier workflows for back-office functions such as sales, marketing, or GitHub automation. The stronger pull came from customers using Trigger.dev inside their products to perform work for end users—examples given include document processing, video encoding, and AI media generation workflows.

   Why it matters: This is an important market distinction: internal automation may validate interest, but deeper product value and stronger infrastructure dependence came from being on the hot path of user-facing applications.

2. Product-market fit reportedly arrived only after Trigger.dev took over code execution itself: In version two, developers used an SDK but still executed work on their own infrastructure. In version three, Trigger.dev provided the SDK plus platform and execution layer. The founders say growth accelerated immediately after this change, and that many customers had already assumed Trigger.dev was executing the jobs.

   Why it matters: This suggests the main customer demand was not just orchestration APIs, but managed responsibility. For infrastructure products, reducing operational burden can matter more than offering flexible primitives.

3. Serverless created a structural gap that AI workloads intensified: The founders argue that modern serverless systems work well for short-lived request/response workloads but poorly for long-running tasks. Trigger.dev positioned itself to fill that gap with queues, retries, idempotency, and durable execution, which became especially relevant as AI usage increased.

   Why it matters: This is the causal logic behind the company’s timing: AI did not create the infrastructure gap, but made the gap more painful and more frequent.

4. The founders attribute earlier weak traction partly to solving the problem in the wrong shape, not to lack of market demand: They explicitly say version two 'did okay' but was not product-market fit, and that the issue was not simply absence of demand. Their interpretation is that the market existed, but the product did not match it well enough until the execution model changed.

   Why it matters: For founders and investors, this is a useful pattern: partial adoption can mean the problem is real while the abstraction, ownership boundary, or operational model is still wrong.

5. Developer experience is treated as design, not just interface polish: The team emphasizes careful design of SDK functions and the first few seconds of product understanding, including code-first presentation on the landing page. Their stated goal is to make it 'very, very hard' for developers to fail when using the product.

   Why it matters: In developer tools, design is positioned here as error prevention and adoption leverage. The claim is that API/SDK ergonomics and code legibility are strategic product decisions, not marketing polish.

6. Their open-source posture is permissive, but the hard-to-scale operational layer remains the differentiated managed service: They describe the product as Apache 2.0 open source with most functionality available, while the non-open part is effectively the operational layer for managing and scaling the infrastructure. They note users can run it via Kubernetes/Helm, but scaling it well is hard.

   Why it matters: This is a recognizable open-core/managed-infrastructure pattern: openness helps adoption, while operational complexity preserves monetization.

Strategic implications

• If the founders’ account is accurate, the durable opportunity around AI agents may sit less in agent prompts themselves and more in workflow execution, reliability, context handling, and managed infrastructure.
• Developer infrastructure companies may gain more by owning operational outcomes end-to-end than by exposing modular building blocks customers still have to run themselves.
• Open-source adoption and managed-service monetization can coexist when the hosted value lies in scaling, orchestration, and operational complexity rather than in withholding core APIs.
• Engineering organizations that adopt AI aggressively may need to redesign hiring, review, and testing around verification and judgment rather than around unaided implementation skill.

Signals to watch

• Whether Trigger.dev continues to grow after the initial version-three inflection, since the transcript claims strong month-over-month revenue growth but gives limited current metrics.
• Whether the market increasingly standardizes around managed execution for AI workflows rather than self-hosted orchestration primitives.
• How often AI product teams converge on the founders’ two-part model of agent building: context assembly plus action/generation.
• Whether developer-tool buyers continue preferring permissive open source plus paid hosted infrastructure, or whether self-hosted demand strengthens.

Caveats

• The transcript appears incomplete and includes a tail excerpt marker, so some context may be missing.
• The interview is founder-reported and promotional in nature; claims about product-market fit, growth, and customer usage are not independently verified in the source.
• The title/description mention 'powering 90% AI agents,' but the transcript excerpt does not provide a precise, attributable explanation or metric for that claim.