Make or n8n for your first workflow that runs unwatched

You have decided that something should happen without you watching it. An enquiry arrives and gets acknowledged. An invoice goes unpaid for fourteen days and someone is told. A call ends and the follow-up is drafted before you have left the room.

That is rung 3, and it is the first rung where the AI is not the interesting part. The interesting part is that a server somewhere stays awake.

Why it cannot be your laptop

This is the question that stalls most people, because the desktop AI app they just started using feels like it should be able to do this. It cannot, and the reasons are mechanical rather than a matter of the model being good enough.

• The machine has to be on. A workflow living in a desktop chat app runs only while the app is running, on a powered, awake, connected laptop. The invoice arrives at 2am regardless.
• There is no inbound trigger. Desktop apps cannot expose a public web address for another system to call. “When a payment lands” requires a server that other software can reach.
• There is no retry and no log. When a chat session fails, it fails silently. You find out from the customer.
• The credentials live on one machine. That is a single point of failure and a security problem at the same time.

Even the vendors concede this in their own products. ChatGPT’s scheduled tasks feature caps out at a small number of active tasks at roughly hourly frequency, with no external integrations, and it mostly notifies you rather than acting. It can tell you a lead emailed. It does not reply to the lead, file the email, or book the follow-up.

So: AI writes the workflow, a platform runs it. They are complements, not substitutes.

What the subscription actually buys

It is worth naming, because at first glance nine dollars a month for a drag-and-drop editor looks like a lot for a drag-and-drop editor. You are not buying the editor. You are buying five things:

1. Hosting and uptime. Someone else’s servers, someone else’s pager.
2. Connector maintenance. When Google or Stripe changes an API, the platform fixes it for every customer at once. A hand-built integration breaks silently and individually.
3. Credential management. OAuth tokens that refresh themselves, secrets stored somewhere other than a laptop.
4. Retries, error routes and execution logs. The infrastructure nobody writes for themselves until after the first outage.
5. An artifact someone else can read. A workflow a colleague — or a future AI agent — can open and modify, rather than a script on a departed freelancer’s machine.

Put another way: you are not paying twenty-nine dollars a month for software. You are paying twenty-nine dollars a month to not employ the fraction of an engineer who would otherwise keep this alive.

The actual choice

Feature comparisons between these two are a waste of an afternoon. Both will do your first workflow. The decision is about maintenance.

Choose Make if you are not technical and you intend to maintain this yourself. It is browser-only, nothing installs, and the free tier is enough to find out whether the workflow was a good idea. Pricing is in credits, which is annoying but not dangerous at small volumes.

Choose n8n if you have run a server before, or someone near you has. The self-hosted community edition is free and runs anywhere Docker runs, which means a small cloud server you are now responsible for. Its hosted plans price by execution count rather than by seat, which usually wins as the team grows and loses if you have one very chatty workflow.

The warning worth repeating comes from people who deploy this for a living: show n8n to a non-technical business owner and their eyes glaze over immediately. That is a fair description of the first ten minutes, and it is the single best reason to start with Make if you are on your own.

Before you build the first one

Two things, in this order, and neither is optional.

Decide where the records live. A workflow that acts needs somewhere to write down that it acted, or you cannot audit what happened while you were asleep. A spreadsheet is not adequate — no proper record identity, no usable API, no protection from two people editing the same row. A database that looks like a spreadsheet is the normal answer.

Build the alert before the second workflow. The standard failure of this category is not a workflow that breaks loudly. It is a workflow that stops running and tells nobody, and is discovered six weeks later. If a failure cannot reach you, you do not have an automation, you have a rumour.

What you should have at the end

One workflow. Triggered by something real. Writing to a record you can look at. With a message that reaches your phone when it fails.

That is rung 3 complete. Everything after it — agents, review loops, work you genuinely stop looking at — is built on exactly this and nothing more.