Trigger.dev Made Background Jobs Fun, or at Least Less Painful

The Macro: Background Jobs Are Boring and Essential

Every non-trivial application needs background jobs. Send an email after signup. Process a payment webhook. Generate a PDF report. Resize an uploaded image. Sync data with a third-party API. These tasks can’t run in the request-response cycle because they take too long, they might fail, or they depend on external services that could be down.

The traditional answer in the JavaScript world has been Bull or BullMQ, which are Redis-backed job queues. They work. They’re also infrastructure you have to manage, and debugging a failed job in a Redis queue is not anyone’s idea of a good time. If you’re in Python, you’ve got Celery, which has been the default for so long that its documentation has fossilized. In Ruby, there’s Sidekiq, which is genuinely excellent but obviously Ruby-only.

What’s changed is that TypeScript has become the dominant language for full-stack development, and the background job tooling hasn’t kept up. If you’re building with Next.js, Remix, or any modern TypeScript framework, your options for running background tasks have been limited to either self-managed Redis queues or serverless functions with aggressive timeout limits. Vercel’s serverless functions give you 10 seconds on the free plan. That’s not enough to send a batch of emails, let alone run an AI workflow.

The rise of AI agents has made this problem more acute. AI workflows are inherently long-running. An agent that needs to call an LLM, wait for a response, make a decision, call another API, and repeat that loop several times can easily take minutes. You can’t do that in a serverless function with a 30-second timeout.

Inngest is the most direct competitor here, offering an event-driven approach to background jobs with a strong TypeScript developer experience. Temporal handles complex workflow orchestration but comes with significant operational complexity. And there’s always the option of rolling your own with a cloud provider’s native queue service, which works until it doesn’t.

The Micro: Four Founders Who Bonded Over JSON

Trigger.dev is an open-source platform for building and running background jobs in TypeScript. You write your tasks as regular TypeScript functions, Trigger.dev handles the infrastructure, retries, scheduling, and monitoring. The platform supports long-running tasks without timeouts, which is the key differentiator from serverless functions.

The founding team is four people. Matt Aitken is the CEO, previously known for creating iPad apps that won Apple’s App of the Year. Eric Allam is the CTO, who co-founded Code School (acquired in 2015). Dan Patel and James Ritchie round out the team. All four previously worked together on JSON Hero, a JSON viewer, which is a fun origin story. They went from “let’s make JSON less ugly” to “let’s fix background infrastructure.” YC Winter 2023 batch.

Eric’s Code School exit is worth noting because Code School was a developer education platform. He’s been building tools for developers for over a decade, which means the developer experience instincts are practiced, not theoretical.

The product has 14,000+ GitHub stars, which is a strong signal in the open-source developer tools space. For reference, Bull has about 15,000 stars and has been around since 2013. Trigger.dev getting to that level of community interest in a fraction of the time suggests genuine pull.

The technical approach is smart. Tasks are defined as TypeScript functions with decorators that handle retry logic, concurrency controls, and scheduling. The platform provides a dashboard for monitoring and debugging, which is where most background job solutions fall short. Writing the job is easy. Figuring out why it failed at 3 AM is the hard part.

Pricing starts free and goes up to $500+/month for enterprise. The free tier is important because it lets developers try the platform in real projects before committing budget. The $30/month hobby tier and $150/month pro tier are reasonable for the value of not managing your own job queue infrastructure.

The integration list is extensive: Vercel, AWS, Remix, Nuxt, SvelteKit, Fastify, Astro, Cloudflare, and more. That breadth matters because developers want background jobs to work with whatever framework they’ve already chosen, not the other way around.

The recent positioning shift toward AI agents and workflows is a calculated bet. “Background jobs platform” is a $30/month sale. “AI workflow infrastructure” is a $500/month sale. The underlying technology is the same, but the framing opens up a much larger market.

The Verdict

I think Trigger.dev is in a strong position. The TypeScript background job market is underserved relative to Python and Ruby, and the timing aligns perfectly with the AI agent wave, which needs exactly this kind of long-running task infrastructure.

At 30 days, I’d want to see reliability numbers. Background jobs are infrastructure. Infrastructure can’t go down. The question isn’t whether Trigger.dev works in the happy path. It’s whether it handles failures, retries, and edge cases gracefully enough that teams trust it with production workloads.

At 60 days, the AI workflow positioning needs to prove itself. Are teams actually building AI agents on Trigger.dev, or is it still primarily used for traditional background tasks like email sending and webhook processing? The revenue growth story depends on moving upmarket from commodity jobs to complex workflows.

At 90 days, the open-source versus hosted split becomes interesting. With 14,000 GitHub stars, a meaningful number of teams are self-hosting. That’s great for adoption but doesn’t generate revenue. The conversion rate from open-source users to paid cloud customers will determine whether this is a venture-scale business or a beloved open-source project.

The founding team has the right combination of developer empathy and shipping speed. The Code School exit proves Eric can build products developers actually adopt. The GitHub traction proves the product has pull. The AI workflow positioning proves they’re thinking about the market, not just the technology.

I’d use it for the next project that needs background processing. Which, given the state of modern web development, is basically every project.