Make

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 Make — and understand the verdict before starting.

**Two thousand maintained connectors** is what the subscription buys, and it is not reproducible. But almost nobody uses two thousand: most people run four or five scenarios against services they could call directly. Writing those four is less code than the configuration describing them, and it never breaks because somebody 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
- List the scenarios you actually run and the services each touches. That list is the project
- Write an 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

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
- 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 immediately and queueing
- Schedule with a cron expression and a time zone, both daylight-saving transitions tested
- 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
- Manual, with a payload typed by hand, which is how a flow is tested

STEPS
- HTTP request with full control and a declared retry policy
- Branch, loop over a list with a concurrency limit, delay, stop with a reason
- Transform with a small expression language over the 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 order twice is a refund
- 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 a one-button replay
- Rate limits per service, honouring the API's own headers

THE INTERFACE
- A flow as a vertical list of steps with branches indented. 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 single detail separates a usable tool from a frustrating one
- A run view with every step expandable, and runs filterable by status with failures first

SECRETS
- Connections encrypted at rest, decrypted only in the worker
- OAuth refresh under a lock, so two workers cannot invalidate each other
- Redacted from every stored payload and 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 — they are the bulk of the data
- Nightly backup off the machine, restore script
- Health endpoint reporting queue depth and expired leases

WHAT MATTERS MOST
Idempotency and the stored payloads. 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.