Lesson 88.1 gave you a verified event flow on paper. Now you must put it somewhere that runs: a node on a canvas, a scenario, a Zap, or a few lines of code on your own server. Beginners usually ask "which tool is best?" — the wrong question. The right question is "which home fits this workflow's sensitivity, complexity, and maturity?"

The vocabulary, in plain language

• Automation platform: a hosted service that runs workflows for you — trigger, steps, logging, retries included. The apartment building: maintenance handled, rules apply.
• Node / step: one box in a visual workflow — "watch for webhook," "create CRM contact," "send email." Data flows from box to box.
• Connector: a prebuilt box for a specific app — "add row to Sheets," "create HubSpot contact." Fast when it fits; awkward when it doesn't.
• Credential: the stored key or OAuth grant a node uses to act as you (Lesson 88.3 governs these).
• API call: the raw alternative — your workflow speaks directly to the app's API with exactly the permissions and fields you choose.
• Custom code: a function or script step (or a small service) you write — full control, full responsibility.
• Self-hosted workflow: an automation engine you run yourself (e.g. n8n self-hosted) — you own the server, the data path, and the uptime.

The mental model: platforms are rental kitchens — fast to start, someone else fixes the oven. Code is your own kitchen — any recipe, but you fix the plumbing. Self-hosting is owning the building.

The four candidates, honestly compared

| | n8n | Make | Zapier | Custom code |

|---|---|---|---|---|

| Best at | flexible branching, self-host option, code steps when needed | visual scenarios with rich data mapping | largest app catalog, fastest simple Zaps | exact control, signatures, idempotency |

| Docs | n8n docs | Make help | Zapier help | your repo + provider docs |

| Cost shape | hosted seat/executions or self-host infra | operations-based | task-based, rises fast with volume | dev time + infra you already run |

| Reliability | good; self-host = your uptime | good, strong execution logs | very good for standard paths | as good as your tests + monitoring |

| Sensitivity | self-host keeps data in-house | data passes through Make | data passes through Zapier | data stays where you put it |

| Skill | low start, grows with you (JS/Python steps) | low-moderate | lowest start | needs a builder |

No tool wins generally. The fit depends on the workflow. A useful rule from the outline: experimental workflows belong on platforms; core money-and-access workflows graduate to code (or self-hosted) once proven.

The decision factors, in order

1. Sensitivity — money movement, access grants, personal data? Prefer paths where secrets and payloads stay minimal and auditable (often code or self-hosted). A newsletter signup can live anywhere. 2. Complexity — two steps with a standard connector? Use the platform. Signature verification, idempotency lookups, branching retries? Code stops fighting the canvas at that point. 3. Reliability need — how bad is a missed run? Core flows (Lesson 88.1's checkout→access) need the error queue, logs, and alerts you can actually inspect at 2 a.m. 4. Cost at volume — price the workflow at 10× current volume. Per-task pricing that looks cheap at 100 runs can sting at 10,000 (Lesson 89.2 returns to this). 5. Skill and bus factor — who fixes it when you're away? A canvas the co-owner can read beats clever code nobody else understands (Lesson 89.3). 6. Experimental vs. core — experimenting? Optimize for speed: platform, standard connectors, throwaway credentials. Proven core? Optimize for control: narrowed scopes, dedicated credentials, versioned logic.

Exercise: defend one choice

Create CONNECTOR-CHOICE.md:

# CONNECTOR-CHOICE.md — [Workflow]

## The workflow (one sentence + trigger)
- ___ → ___ (link EVENT-FLOW.md)

## Candidates considered (at least two)
- A: ___ / B: ___ (with docs links)

## Decision table (1–5 or short notes)
- Sensitivity / complexity / reliability need / cost at 10× / skill + bus factor / experimental-vs-core

## Choice + why alternatives wait
- Chosen: ___ because ___
- Revisit when: ___ (volume, sensitivity, or failure threshold)

## Credentials + permissions (preview of Lesson 88.3)
- Dedicated credential, least scope: ___

Worked mini-example — Sonariq follow-up: "completed source collection → validate → review queue." Choice: Make with standard connectors — experimental, low sensitivity (no money), owner can read the scenario. Alternative (custom code) waits until volume justifies it. Counter-example: checkout→access from Lesson 88.1 — custom code endpoint for signature verification and idempotency, because sensitivity and correctness outweigh canvas convenience. The CRM update step after verification can still be a platform connector.

Finish line: a CONNECTOR-CHOICE.md naming one home, scoring it on all six factors, and stating the revisit trigger.

Verify quickly: hand the file to a friend. If they can say "this runs on ___, not ___ because ___," it works. If they ask "so which one?", the decision table failed.

Common failure mode: the forever-prototype — a core money flow living on a personal Zapier account with a master API key, no error queue, and no second person who can fix it. Fast start, fragile core. Lesson 88.3 and 89.3 fix exactly this.

Check your understanding

1. When does custom code beat a visual platform, even though it's slower to start? 2. Why should experimental and core workflows live under different rules? 3. Price your flow at 10× volume — what changes about the "cheapest" option?

Next

The home is chosen. Now the keys: Lesson 88.3 locks down permissions, secrets, and least privilege so the workflow can act — and nothing more.