u/yuuliiy

I got tired of seeing this question tool-by-tool so I wanted to share a framework that's held up pretty consistently across different use cases.

Here's how I think through it, having worked with teams in different sizes:

Use Zapier if: Your team is non-technical and needs to own the workflow independently. The trigger/action is simple and unlikely to change. You need it running this week. The moment a workflow needs conditional logic more than 2 levels deep, Zapier starts fighting you.

Use n8n if: You have at least one person who is comfortable reading JSON and won't panic when a node errors. You need branching logic, sub-workflows, or custom code steps. You want self-hosted for cost or data reasons. n8n's ceiling is much higher than Zapier's, but its floor is also lower. Broken workflows require someone to actually fix them.

Use Relay if: The workflow has humans in the middle of it and that's not going away. Approvals, handoffs, review steps, routing, notifications, escalation paths, the stuff that sounds simple until 5 people touch the same process across Slack, email, docs, and internal tools. Relay makes more sense to me when the problem is operational coordination rather than pure automation.

Go custom if:
The workflow is core to how your product or ops works and will change frequently. You're integrating with internal systems that have no pre-built connectors. You need full observability (logs, retries, alerts) baked into the system, not bolted on. Custom costs more upfront and needs a real engineer, but it pays back when the workflow scales or the requirements shift.

The mistake I see teams often make is starting with Zapier, hitting the ceiling, migrating to n8n, then eventually building custom, wasting weeks or even months instead of making the right call once.

The answer almost always depends on team composition, not the workflow itself.

What made you choose the stack you're on? And what would you do differently?

I work at a healthcare company composed of 38 people and a small engineering team. A SOC 2 Type II audit coming up in three weeks that requires us to demonstrate that critical workflows across all production systems execute correctly and are monitored. The auditor scope did not distinguish between web and desktop. Both needed documented coverage.

The first is our main web portal. Modern stack, we have Playwright tests covering the critical flows, not perfect but solid enough.

The second is a legacy desktop billing application we inherited two years ago when we acquired a smaller company. It has no API. It runs on Windows only. The UI is from roughly 2011 and it has not been updated in years.

Our dev team looked at this for two days and came back saying it would require two completely separate test frameworks with no shared infrastructure. One for the browser, one for the desktop. Double the setup, double the maintenance, double the cost.

We brought in an offshore QA contractor to evaluate options but gave us the same answer.

Three weeks to the audit and we are sitting on a coverage gap for the desktop environment that we have no clean solution for.

Has anyone here dealt with cross-environment test coverage requirements across both web and legacy desktop in the same SOC 2 audit scope? What did you actually do?

Junior sales rep here, I started three weeks ago selling packaging materials to food manufacturers and industrial producers. I got handed a list of 2,000 companies, a car, and a weekly visit quota.

The problem is I have no idea how to prioritize. I keep driving to places that turn out to be too small, already locked into a competitor, or just completely wrong for what we sell. I asked my manager how to decide and he said to use my instincts, not super helpful when you're three weeks in.

Most of these businesses have basically no online presence so looking them up before visiting tells me almost nothing. Is there a more systematic approach to prioritizing a territory when you have almost no data on the companies in it, or is this genuinely just something that comes with experience?

I am building a practical migration resource for Vue 3 developers moving to React 18 and 19. I want to focus it on the real struggles, not high-level comparisons.

I have already identified a few pain points that come up often. Losing v-model and learning controlled components. Stale closures and dependency arrays replacing automatic reactivity tracking. Replacing scoped slots with composition patterns. Shifting from Pinia stores that allow direct mutation to immutable state libraries like Zustand or Redux. Understanding useEffect and its mount, update, and cleanup model after using onMounted and watch.

What would you add? I am looking for the single most confusing thing you had to unlearn, or the mistake you saw a teammate make repeatedly. I want to know what existing guides miss.

I will send the finished free resource to anyone who shares their experience. Thank you for the insight.

I am building a practical migration resource for Vue 3 developers moving to React 18 and 19. I want to focus it on the real struggles, not high-level comparisons.

I have already identified a few pain points that come up often. Losing v-model and learning controlled components. Stale closures and dependency arrays replacing automatic reactivity tracking. Replacing scoped slots with composition patterns. Shifting from Pinia stores that allow direct mutation to immutable state libraries like Zustand or Redux. Understanding useEffect and its mount, update, and cleanup model after using onMounted and watch.

What would you add? I am looking for the single most confusing thing you had to unlearn, or the mistake you saw a teammate make repeatedly. I want to know what existing guides miss.

I will send the finished free resource to anyone who shares their experience. Thank you for the insight.