Should I vibe code
Build a small human-in-the-loop workflow across two approved services
Relay is deleting your workflows in September. Whatever you build has to survive that, with you as the vendor.
?
Their verdict, the price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
One fact outranks the verdict here: Relay.app is winding down. Signups closed on 16 July 2026, free workspaces are deleted after 15 August and paid ones after 14 September, and everything you did not export goes with them. Sit with that for a second, because the usual closing argument on this site is "just pay the nineteen dollars", and this month that argument has an expiry date. Now the build. Firing an HTTP request when something happens is an afternoon. What Relay actually sold is the layer above it: a workflow that pauses for a human to approve a draft, resumes days later with its context intact, retries the flaky step without repeating the step that already sent, and can prove afterwards what ran. Doing that properly means durable state, idempotency keys, dead-letter handling and a token vault holding long-lived OAuth grants for a dozen services you do not control. You can absolutely build this. What you build is a small unattended machine that acts on your behalf, holds every credential you own, and stops being interesting to you long before it stops running.
What actually breaks
not "if". the specific failures.
- The credential store, which is the real product: refresh tokens for Slack, Gmail, HubSpot, Notion and Stripe, long-lived, in one database, on a box you last patched at setup
- Silence. Success is invisible in automation, so a workflow that stopped firing three weeks ago looks exactly like a quiet month
- Steps that are not idempotent, where a retry does not resume the run — it sends the second email
- The pause. Human-in-the-loop means a run that has to survive days of waiting, a deploy, a restart and a schema change, and still know exactly where it was
- Approval semantics nobody specifies until they bite: what happens when nobody clicks for a week, whether a timeout means proceed or abandon, and who is allowed to click at all
- Every connector, forever. Each one is somebody else's API, rate limit, pagination style and breaking change, on their schedule
- Ordering and concurrency, once two triggers fire for the same record and both branches write to the CRM
- The audit question, asked after the fact: which runs executed, with what inputs, and what did they send — answerable only if you decided to store it before you needed it
The workflow has not run since the 14th. You learn this on the 4th of the following month, when a customer asks why nobody replied to the form they submitted three weeks ago, and then asks — reasonably — how many other people are in the same position. The trigger was a webhook. Your endpoint began returning 500 after a dependency bump, the sending service retried politely for six hours and then gave up, quietly, the way well-behaved services do. Nothing alerted, because your alerts fire on failures and this was not a failure on your side; it was an absence, and absences do not page anyone. You spend the morning reconstructing which submissions never reached the CRM from three logs that share no identifier, and the afternoon writing twenty-two apology emails. Four of those go to people who did get a reply, because your reconstruction was wrong, and that is the part they remember.
Is that you?
the verdict is a default, not a law
- It is your own automation, running against your own accounts, and the worst outcome is that you do a thing manually for a week
- Every action is idempotent or reversible: writing a row, updating a record, filing a document — not sending, paying or publishing
- It is a folder of small scripts on a scheduler rather than a platform, because a folder of scripts is legible and a platform is a product
- The output reaches customers. An automation that emails, invoices or messages people has no undo, and its failure mode is a message you cannot recall
- Anyone but you depends on it running, because nothing about it announces that it has stopped
- You are storing OAuth refresh tokens for other people's accounts, which turns a side project into a credential store with a public IP
- You would be rebuilding it in a hurry this month because Relay is closing — a migration deadline is the worst possible moment to start owning an integration layer
If you build it anyway
the checklist, then the prompt that enforces it
- Store credentials in a real secret manager, encrypted at rest with a key that is not in the same database, and hold the shortest-lived token the provider will issue.
- Give every run an idempotency key and pass it to every side-effecting call. A retry must be provably safe before retries are enabled at all.
- Alert on absence, not just on errors: a heartbeat per workflow and a dead-man's switch that fires when an expected run does not happen.
- Persist run state after every step, keyed to a durable run id, so a pause for human approval survives a restart, a deploy and a week of waiting.
- Give approvals explicit semantics — a timeout, a default action, an authorised approver — and write them down where the workflow is defined.
- Send everything that fails terminally to a dead-letter queue you can inspect and replay by hand. A dropped item with no record is the thing you cannot recover from.
- Keep an append-only run log with inputs, outputs and timestamps. It is the only way to answer "what did it send" a month later, and you cannot backfill it.
- Define workflows as files in version control, not rows in a database, so the whole system is diffable, reviewable and portable to whatever replaces it.
I am building a small workflow automation service: triggers, steps across a few
SaaS APIs, and a pause for human approval. Reliability and credentials come
first; the builder UI comes last, if ever.
1. Before any workflow logic, design credential storage: a secret manager, or
an encrypted table whose key lives outside the database. Shortest token
lifetime the provider supports, automatic refresh, documented revoke path.
2. Then durability. Every run has an id and persists state after each step. A
restart mid-run must resume — prove it by killing the process mid-run.
3. Every side-effecting step takes an idempotency key derived from the run and
step id, and retries stay off until that exists.
4. Classify every step in its definition as reversible or not. Anything that
sends, pays or publishes is irreversible: no automatic retry, no unattended
execution I have not approved by name.
5. Build the dead-letter queue before the happy path is pretty: terminal
failures land somewhere I can see and replay one at a time.
6. Add heartbeats and a dead-man's switch now. If a daily workflow has not run
in 36 hours, notify me: alerting only on errors never catches a trigger that
silently stopped, which is the failure I actually care about.
7. Approvals need semantics before implementation: who may approve, what a
timeout does, what happens when the approver has left. Ask me rather than
defaulting to proceed.
8. Append-only run log from the first run — inputs, outputs, timestamps, step
results — with secrets redacted on the way in.
9. Workflow definitions are files in version control — no visual builder, no
rows in a table as the source of truth.
10. Rate-limit per provider, cap actions per hour, and give me a kill switch I
can flip without deploying.
11. Out of scope, and say so: multi-tenant use, holding anyone else's OAuth
tokens, a connector marketplace. If I am migrating off a service that is
shutting down, tell me to port one workflow properly, not all of them badly.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
There is nothing to buy here any more, which is the whole point of this page. If you were about to depend on Relay, the honest alternatives are Zapier or Make if you want it hosted and boring, n8n or Activepieces if you want to self-host something with an actual community behind it, and a folder of scripts on a scheduler if the automation is only yours. Whichever you pick, pick it for the export format as much as the feature list.
Keep the definitions as files and the run log as append-only rows, and the exit is a matter of reading them. That is exactly the exit Relay is offering its own customers right now — workflows and prompts as JSON, run history and tables as CSV — and it is worth noticing that the export is the part everyone is grateful for. Build yours on day one; you will need it either when you quit or when the next platform closes.
Active open-source automation platform with connectors and durable workflow execution.
Fair-code workflow automation with several hundred integrations, self-hostable and very actively developed.
Open-source developer platform for scripts, flows and approval steps, with durable execution as a first-class feature.
Questions
Relay is shutting down. Does that make building it yourself the right call?
It makes it a more honest call, not an easier one. The shutdown removes the option of paying somebody else to hold the pager, but it does not change what holding it costs. If you are migrating under a deadline, port the one workflow that actually matters onto something maintained, and leave the other eleven manual until you have time to think.
How is this different from the Zapier entry?
Zapier's page is about retries — a loop without them drops work, a loop with them sends twice. This one is about the pause and the silence: human-in-the-loop means runs that must survive days of waiting and a deploy, and a trigger that quietly stops firing produces no error at all, which is a much harder thing to notice than a duplicate.
What is the smallest version worth building?
One workflow, in one file, on a scheduler, with a heartbeat that shouts when it does not run. No builder, no connector abstraction, no database of definitions. That version is genuinely better than a subscription and you can read the whole thing in a sitting.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Retries are the feature. A loop without them silently drops work; a loop with them sends it twice.
An automation hub is a box holding every API key you own, wired to the internet.
A handful of personal scripts beats an applet platform you have to keep alive.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice