Should I vibe code
Visual automation platform for scenarios across apps and APIs
The canvas is not the product. The queue of half-finished runs you can fix and resume is the product.
?
Their verdict, the Core 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
A scenario is a program, and Make is an execution environment wearing a canvas as a disguise. The Zapier entry makes the case about retries and idempotency and all of it holds here, so this one is about what Make adds: routers, iterators, aggregators and error branches let people build things that would be a small service if written by hand, and the feature that saves them is the least exciting one on the whole site — the queue of incomplete executions, where a run that failed halfway is parked with its payload so a human can fix the cause and resume it. Your version will catch the exception, log the word "error", and drop the order. Everything upstream of that step already happened.
What actually breaks
not "if". the specific failures.
- The half-applied run. Step three created the invoice, step four threw, and nothing in your system knows the world is now in a state no code path expects
- Credential refresh across a dozen OAuth apps — the token that rotates on every use, the one that expires after ninety idle days, the one that dies quietly when someone changes a password
- Iterators at volume. Fine across the twelve rows you tested, then four thousand calls into an API with a hundred-per-minute limit on the morning somebody exports a big spreadsheet
- Retries that are not idempotent, which is how one webhook becomes three identical Slack messages, two duplicate refunds and a very confusing support ticket
- Silence. A scheduled scenario that has stopped running looks exactly like a scheduled scenario with nothing to do, and nothing pages you about an event that did not happen
- Run history. Storing payloads is the only way to answer "what did it actually send" — and it is also a database of every record that has ever passed through your automations
A supplier’s API starts answering 200 with an empty body. Your automation reads a 2xx as success, marks forty purchase orders sent, and moves on. No retry fires, because nothing threw. You find out four days later when the supplier calls to ask why the week’s orders never arrived, and the only evidence you have is forty log lines that say OK with no payload beside them, because payload retention was the setting you turned off in March when the disk filled up.
Is that you?
the verdict is a default, not a law
- One trigger, one action, your own data, and you would notice within the hour if it stopped
- Everything it touches is idempotent, or trivially reversible by you
- It is glue between two systems you own, not a step somebody outside is waiting on
- It sends anything outward — email, invoices, messages to customers, records into someone else’s CRM
- It holds OAuth tokens for accounts that are not yours
- You cannot answer "did it run at 04:00, and what exactly did it send"
- A duplicate execution would move money, or a skipped one would lose an order
If you build it anyway
the checklist, then the prompt that enforces it
- Every outbound side effect carries an idempotency key derived from the input, and that key survives a process restart. This is the difference between a retry and a duplicate.
- Persist the run before executing it — input payload, current step, status — so a failure is inspectable rather than merely logged.
- Build the dead-letter queue first. Failed runs park with their payload and are resumed deliberately; nothing is retried into oblivion.
- Heartbeat every scheduled job to an external monitor. The absence of an error is not success, and only an outside observer can tell you a run never happened.
- Validate responses, not status codes. A 200 with an empty body is the failure that gets past everybody.
- Credentials live in a secrets store, scoped per connection, refreshed on a schedule, never logged and never rendered into an error message.
- Cap fan-out. A run that would make more than N outbound calls stops and asks, because the rate-limit cliff arrives on the day the input is unusually large.
I am building a workflow automation runner that connects APIs on a schedule and via webhooks. Treat it as a job system with side effects, not as a canvas.
1. Persist a run record before executing anything: input payload, step index,
status, timestamps. A run I cannot inspect afterwards is a run I cannot
fix, and that is the failure mode of this whole category.
2. Build the dead-letter queue and a manual resume path before you build the
second integration. Failed runs park with their payload; nothing is
silently dropped or infinitely retried.
3. Every outbound side effect takes an idempotency key derived
deterministically from the input, stored before the call and checked
after a restart. Show me what happens if the process dies mid-step.
4. Validate response bodies, not just status codes. Treat a 2xx with an
unexpected or empty body as a failure and park the run.
5. Credentials go in a secrets store, one scoped credential per connection,
refreshed on a schedule. Never log a token, never include one in an error
message, and never write one into the run history.
6. Add an external heartbeat for every scheduled job so a scenario that stops
running raises an alert. Nothing else will tell me.
7. Cap fan-out per run, and respect each API’s rate limit with backoff and
jitter. If a run would exceed the cap, stop and ask me.
8. Anything that sends email, messages a customer, or writes to a system I do
not own goes behind an explicit confirmation flag and starts disabled.
9. Set payload retention deliberately — long enough to debug, short enough
that I am not accumulating everyone’s records forever — and write the
window into the README.
10. Out of scope, and say so instead of faking it: a visual builder, a
connector marketplace, and multi-user access. If I want more than a
handful of automations, tell me to price Make or run n8n instead.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
The first time an automation touches a system you do not own. Nine dollars a month rents an execution engine with a run log, a resumable failure queue and a couple of thousand connectors whose OAuth refresh is someone else’s pager — and the credit-based pricing means a runaway loop shows up as a bill rather than as a suspended API account. n8n and Activepieces are the self-hosted middle: you still run it, but you are not the one writing the retry semantics.
$9/mo is cheaper than your weekend.
Keep each automation as small, self-contained code with its configuration in version control and its secrets outside it. That is the only form that survives — a scenario in your own visual builder exports to precisely one thing, your own visual builder. Write down, per automation, what triggers it, what it writes to, and which credential it uses; that list is what you will need on the day you move to Make, n8n or Activepieces, and it is what nobody ever has.
Open-source automation platform with triggers, actions and a run history you did not have to design.
Fair-code workflow engine, self-hostable, with error workflows and execution retries already solved.
Questions
How is this different from the Zapier entry?
Zapier is where the argument about retries, backoff and credential refresh lives. Make earns its own page because its shape encourages bigger builds — routers, iterators, aggregators, error handlers — so what you would be reimplementing is not an integration but an execution engine with a run history, and the ambition is what turns a broken step into a half-applied business process.
What is the single feature people forget to build?
Incomplete executions. Make parks a run that failed partway through, with its data, so you can fix the underlying problem and resume it. Homemade versions catch the exception and log it, which means the order that was half-created stays half-created and nobody knows until a human complains.
Is a cron job and a script really that bad?
For one automation over your own data, no — that is the shipItIf case and it is a good answer. It stops being fine when there are eleven of them, three of which write into systems you do not own, and none of which tell you they have stopped.
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-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice