n8n used where it improves the product.

Make is quicker for non-developers and fully hosted. n8n suits more complex branching, custom code steps, and cases where data cannot leave your infrastructure because it can be self-hosted. The deciding factors are usually who will maintain the workflows and whether self-hosting is a requirement, not the node count either platform advertises.

Self-host when data residency, compliance or per-execution pricing at your volume makes it worthwhile, and when someone will own the server. It is a real operational responsibility — updates, backups, queue mode for concurrency, and monitoring. Cloud hosting is the right default until one of those constraints genuinely applies.

Whatever you designed, which is why it needs designing. Without error handling a partial run leaves records half-processed with no record of where it stopped. Reliable workflows use idempotent steps, checkpoints, an error branch that alerts a named person, and enough context logged to replay a single failed item rather than the whole batch.

To a point. Per-execution pricing becomes the constraint before technical limits do, and heavily branched workflows get difficult to reason about long before they get slow. A common pattern is keeping orchestration visual while moving the heavy or high-frequency work into a service the platform calls.

Partially, and it is a real limitation. Both platforms support exporting workflow definitions as JSON, which can be committed, but restoring one is not the same as a code deployment and credentials live outside the export. Treat exports as backups and change records rather than as a full deployment pipeline.

Use the platform's credential store rather than pasting keys into node fields, scope each service account to the narrowest permissions the workflow needs, and rotate on a documented schedule. Self-hosted instances need their encryption key backed up separately, since losing it makes every stored credential unrecoverable.

Only if you built for it. Logic held entirely in proprietary nodes has to be rebuilt elsewhere. Keeping business rules in your own code or database, and using the platform mainly for triggering and transport, keeps the exit viable — worth deciding early, because retrofitting it means rewriting the workflows anyway.

This needs naming before they are built. Someone must own alerts, exceptions, and updates when a connected service changes its API. Handover should include the workflow documentation, credentials in your own accounts, and a runbook for the failures already known to be possible.