Zapier

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me the automations I actually run instead of Zapier — and understand the verdict before you start.

**Thousands of connectors, kept working**, is what the subscription buys, and it is not reproducible. But nobody uses thousands. Most people run four or five automations against services they could call directly, and writing those four is less code than the configuration describing them — and it never breaks because somebody else changed a connector. Build that, not a platform.

STACK
- Node 20+ with Fastify
- SQLite through better-sqlite3, WAL mode
- A worker process for the queue
- Server-rendered interface, flows as a list rather than a canvas
- Caddy in front

FIRST, THE SCOPE
- Open your account and list the automations that actually ran last month, and the services each touches. That list is the entire project
- Write one adapter per service you genuinely use — authentication, pagination, rate limits — as a small module with a fixture and a test
- Do not build a connector framework for integrations you have not written. That is how a fortnight becomes a year, and it is the mistake this prompt exists to prevent

THE DATA MODEL
- flows: id, name, version, definition_json, is_active
- flow_versions: id, flow_id, version, definition_json, published_at — a run is pinned to a version, so editing never changes a run in flight
- runs: id, flow_id, flow_version, trigger_payload_json, status, started_at, finished_at, error, dedupe_key
- step_runs: id, run_id, step_id, attempt, status, input_json, output_json, error, ms
- connections: id, service, credentials_encrypted, expires_at, refreshed_at, last_error
- cursors: id, source, value, updated_at
- queue: id, run_id, step_id, run_at, attempts, locked_by, lease_expires_at
- Every step's input and output stored. When a flow does the wrong thing at three in the morning, those payloads are the only thing that answers why

TRIGGERS
- Webhook with a secret and a signature check, answering 200 immediately and queueing
- Schedule with a cron expression and a time zone, with both daylight-saving transitions in the test suite
- Poll a source on an interval with a stored cursor and deduplication by item identifier. A poller that re-emits everything after a restart is the classic disaster in this category, and it is how somebody gets four hundred emails
- Manual, with a payload typed by hand, which is how a flow is tested

STEPS
- HTTP request with full control of method, headers, body, timeout and a declared retry policy
- Branch on a condition, loop over a list with a concurrency limit, delay, and stop with a reason
- Transform with a small expression language over the accumulated run state, or a sandboxed script with a time limit and no ambient network
- Your own service adapters, each declaring its input and output schema

RELIABILITY, WHICH IS WHERE THE REAL WORK IS
- Retries with exponential backoff and jitter, per step, with a maximum
- Retry only what is safe. A non-idempotent action needs an idempotency key, and the step declares whether it has one — sending an email twice is annoying, creating an invoice twice is a phone call
- Deduplication on the trigger, so a webhook delivered twice runs once
- The queue is a table with a lease, so a crashed worker's run is resumed rather than lost
- A permanent failure lands in a dead-letter list with everything needed to replay it, and replay is one button
- Rate limits per service, honouring the API's own headers

THE INTERFACE
- A flow as a vertical list of steps with branches indented beside them. A node-and-wire canvas is more work to build and less readable for the flows people actually run
- The editor shows real sample data from the last run beside every field, so a path is picked rather than typed. That one detail separates a usable tool from a frustrating one
- A run view with every step's input, output, duration and error, expandable
- Runs filterable by status, failures first

SECRETS
- Connections encrypted at rest with a key from the environment, decrypted only in the worker
- OAuth refresh under a lock, so two workers cannot refresh at once and invalidate each other
- Redacted from every stored payload and every log, by key name and value match, including encoded forms

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, ENCRYPTION_KEY, SESSION_SECRET, WEBHOOK_SECRET
- Migrations on boot, each once; step payloads pruned on a stated retention, since they are the bulk of the data
- Nightly backup off the machine, restore script
- Health endpoint reporting queue depth, the oldest unlocked item and any expired lease

WHAT MATTERS MOST
Idempotency and the stored payloads. Build the lease queue and the dedupe key first, then kill the worker mid-run and confirm nothing is lost and nothing repeats. An automation tool that occasionally does something twice is one you stop trusting with anything that matters — which was every reason you had for building it.