- Core transactional email flow? Great.
- Alerting Slack for non-critical activities elsewhere? Ehh...
> 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!
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.
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.
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.
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.
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.
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.