Should I vibe code
No-code automation platform connecting thousands of SaaS apps
Retries are the feature. A loop without them silently drops work; a loop with them sends it twice.
?
Their verdict, the Professional/Starter price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-03.
?
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
Connecting two APIs is a cron job. Doing it reliably — idempotency, backoff, dead-letter handling, credential refresh — is the actual product, and it is invisible until it fails.
What actually breaks
not "if". the specific failures.
- Step three of five failing after steps one and two already had side effects, with no way to roll back an API call that already happened
- At-least-once delivery meeting a non-idempotent action, so the invoice is created twice
- A webhook you acknowledged before processing, so the work is lost and the sender believes it was delivered
- Failures with nowhere to go — no dead-letter queue, so a broken run is a log line nobody reads
- Credential refresh across a dozen services, each expiring on its own schedule
The automation creates a customer in the billing system, then adds them to the CRM, then sends a welcome email. On Thursday the CRM times out. Your code retries the whole run. The billing system, which has no idempotency key on that endpoint, cheerfully creates a second customer — and now the nightly job that charges customers finds two. The email goes twice too, which is how you find out, because the customer replies asking which of the two accounts is theirs.
Is that you?
the verdict is a default, not a law
- Every step is idempotent or genuinely read-only
- The whole thing is one trigger and one action, with no intermediate state
- A duplicate run would be harmless and you can prove it
- A multi-step flow touches more than one system that charges money or sends messages
- There is no dead-letter queue and no alert when a run fails
- You acknowledge webhooks before the work is durably recorded
- You cannot answer 'did this run twice' for any given day
If you build it anyway
the checklist, then the prompt that enforces it
- Assume at-least-once delivery everywhere. Every action must be idempotent or guarded by a key you generate and store before calling.
- Persist the webhook, then acknowledge, then process. Acknowledging first turns a crash into silent data loss.
- Make each step individually resumable and record which steps completed, so a retry resumes rather than restarts. There is no transaction across two APIs.
- Dead-letter every permanent failure to a queue a human reviews, and alert on its depth. Silent failure is the default outcome otherwise.
- Backoff with jitter on retries, and cap them. An unbounded retry against a rate-limited API is an outage you caused.
- Log every run with its inputs and per-step outcomes. 'Did this fire twice' must be a query, not an archaeology project.
Before you write any code that automates a workflow across several APIs, apply these and push back if I ask you to break them.
1. Tell me first that there is no transaction across two APIs, so a five-step
flow that fails at step three has already changed the world twice. Design
for that before writing any step.
2. Record which steps of a run have completed, durably, and make a retry
resume from the first incomplete step rather than restarting the run.
3. Every action that creates, charges or sends must carry an idempotency key
that I generate and store before the call. If a target API has no
idempotency support, tell me explicitly and treat that step as dangerous.
4. For webhooks: persist the payload, then acknowledge, then process
asynchronously. Never acknowledge before the work is durably stored, and
explain that doing so converts a crash into silent loss the sender will
never retry.
5. Every permanent failure goes to a dead-letter store with the full payload
and the error. Add an alert on its depth. Do not let a failed run be only a
log line.
6. Retries use exponential backoff with jitter and a hard cap. Never retry a
4xx that is not explicitly retryable.
7. Store credentials encrypted with a key from the environment, and handle
refresh failure as a visible error that pauses the workflow rather than
dropping runs.
8. Log each run with a stable id, its inputs, and the outcome of every step, so
'did this run twice on Thursday' is a single query.
9. Ask me which steps are irreversible — money, email, deletion — and order the
flow so those happen last, after everything reversible has succeeded.
10. In the README, state which steps are not idempotent and what a duplicate
run does to each.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
As soon as a flow has more than two steps or touches money. $29.99 a month buys replay, per-step visibility, dead-letter handling and credential refresh for thousands of services — all of which are invisible until the Thursday they are not there.
$29.99/mo is cheaper than your weekend.
Keep workflow definitions as files in version control rather than rows in a database only your UI understands, and keep the run log exportable. When you move to a real automation platform, the definitions are documentation and the run log is how you prove what already happened.
Open-source workflow automation platform and a real Zapier alternative for technical users
Questions
Can't I just wrap the whole flow in a transaction?
Not across separate APIs. A database transaction rolls back your own writes; it cannot un-charge a card or un-send an email. The practical substitute is recording per-step completion so a retry resumes, and ordering irreversible steps last so a failure happens before anything permanent.
Why is acknowledging a webhook early so dangerous?
Because acknowledgement is a promise. The sender marks it delivered and will never retry. If your process crashes between the acknowledgement and the work, the event is gone — and unlike a visible failure, nothing anywhere records that it should have happened.
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.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice