[robbiemitchell]

Speaking as a tech-forward "business user" who uses Zapier _a lot_: a key benefit of Zapier is that it enables business users to work independently. Moving triggers and actions behind "developer-friendly" (i.e., developer-required) tooling caps how fast an organization can move on anything outside the critical path for product and strategy.

- Core transactional email flow? Great.

- Alerting Slack for non-critical activities elsewhere? Ehh...

[lolinder]

They already address that specifically:

> We found current workflow / automation tools like Zapier and n8n are good for simple tasks, but not for more advanced use cases.

This isn't intended to replace Zapier for your use case.

Speaking as a developer who's been asked to set up integrations before, I'm glad to see more competition in this space with a developer focus!

[robbiemitchell]

The first example on the homepage is "Create an email drip feed campaign in under 2 minutes"

This is not an advanced use case to be developed in house and owned by developers. This is bread and butter marketing or product engagement email flows using anything from Mailchimp to customer.io to HubSpot.

The developer side would involve capturing the identities and events from your system and sending them (typically via something like Segment) to the downstream tools, where business users will manage those campaigns: flows, templates, content, integration with other flows, and reporting.

The next example is "Sync GitHub issues to Linear". Again, this is a fairly simple Zapier use case, probably using built-in integrations, or falling back to Python if needed. Zapier would store the credentials to both security and use a trigger/action flow.

I can see trigger.dev being more useful for things like:

- Schedule-based tasks, or super high-volume tasks. (These are expensive on platforms)

- That are driven primarily by code, not pre-built integrations

- Using private data (such as authorization tokens) you don't want to expose in plain text

Given there is undoubtedly a market of developers who want to bring things back into their standard codebase and code release practices, I suggest targeting the examples to situations to those more typically owned by developers.

[mattaitken]

Thanks, this is great feedback. You're right that these examples don't highlight the real advantage of our platform vs no-code tools. We're going to add some new examples to our site based on what our customers are building.

The three categories of problems you identified that are best solved with a code tool are what we're seeing with our early customers. Plus a lot of notification use cases like when developers want to be notified in Slack when something important/bad happens.

[eallam]

Zapier is great for non-developers, and as developers we've even used Zapier in the past because in some simple cases it's actually easier and more reliable than writing the code yourself! It's not easy to write code that connects even just a few services together, and handles transient errors and server interruptions, usually it takes some kind of infrastructure and maintenance, and can no longer be written in the normal way (and good luck with delays!).

We wanted to bring the convenience of Zapier (you describe the request you want to do, they figure out how to do it!) back into our codebases, without having to manage a bunch of infrastructure (that's where trigger.dev comes in).

While we were at it we built this as a general purpose event-driven system, complete with AWS Event Bridge like event pattern filtering, and also added the ability to listen for webhooks reliably without having to use a tunnel to your local machine when testing locally.

[michaelmior]

> It's not easy to write code that connects even just a few services together, and handles transient errors and server interruptions, usually it takes some kind of infrastructure and maintenance, and can no longer be written in the normal way (and good luck with delays!).

Based on the example shown, it looks like Trigger.dev handles all this while allowing you to write code pretty close to what I would call "in the normal way." I haven't tried it myself, but if the examples work as advertised, it looks pretty attractive to me.

[bradgessler]

It’s not hard to imagine a template library or code generator that sits on top of this code layer that’s more approachable to non-technical users.

If done well, that would be an advantage over Zapier since a non-technical user can start something basic, then have a dev look at it if they need to get more sophisticated.

This is what has made Excel and Access so successful—a biz person can get it started and have something tangible to hand off to a dev.

[aliqot]

and suddenly at least one of us realizes why zapier costs money. the cycle continues.

[carrja99]

Comes up all the time. There was another tool like this (huggin?).

I think what often gets missed and what gives zapier great power is the developer platform that can let devs build anything! I have a lot of custom integrations with apps that support use cases that afaik only I have. It is incredible effective.

[eddieroger]

I had a lot of bots in Huginn, but the amount of tending that the garden required versus and the developer experience were never good enough that I kept them going. I found myself doing all the JS editing I needed in VSCode and coping it back and forth, which is a bad experience. It definitely saved my butt a few times over the last few years, but I am anxious and excited to swap it out for this.

[bluehatbrit]

Did you mean Huginn? (https://github.com/huginn/huginn)