Automate your CRM with Make and n8n.
Why we reach for visual orchestrators before we reach for code — and the four moments when we do reach for code anyway.
Most of the Operate playbooks we ship live inside Make or n8n — visual flow tools where every step is a node on a canvas. People sometimes ask why we do not just write the code. The answer is selfish: visual flows are the easiest thing in the world to hand back.
When we leave a project, the client opens the canvas and sees what is happening. They do not need to read TypeScript. They do not need to remember which file the Stripe webhook lives in. They see Stripe → QuickBooks → Google Sheets, with a label on each connector, and they understand the flow in fifteen seconds.
What visual orchestrators do well.
- i.Glue between SaaS tools. Stripe, HubSpot, QuickBooks, Notion, Slack, Google Sheets. Hundreds of pre-built connectors with auth flows handled. You will write zero lines of OAuth boilerplate.
- ii.Visible state. Every run shows up as a row of colored dots. A red dot is an error. A green dot is a success. The client can scan the last week of runs without opening logs.
- iii.Cheap iteration. Adding a step is three clicks. Try it, watch it run, undo it. There is no deploy step.
- iv.Handoff. Most clients can edit their own flows after a thirty-minute walkthrough. None of them want to, but the option matters.
Make vs. n8n — the actual difference.
Both work. We use both. The shorthand we use internally:
- i.Make for clients who will never log in. Polished UI, generous free tier, reliable execution. The client sees a dashboard and that is the extent of their interaction.
- ii.n8n for clients who want to peek under the hood, or who are nervous about cloud-only data. Self-hostable, open-source, lets you drop into JavaScript when a node does not exist for what you need.
We tend toward n8n for clients in healthcare, legal, or finance — anyone whose data needs to live somewhere they control. Otherwise Make wins on first-day polish.
The four moments we reach for code.
- i.Custom logic over five branches deep. Visual flows become unreadable past about five if/then forks. At that point a single TypeScript function is clearer.
- ii.Bilingual prompt assembly. Building a prompt for the LLM — with multiple inserts, fallbacks, and language selection — is unbearable in a visual canvas. We extract that into a small Cloud Function.
- iii.Real-time anything. Visual orchestrators run on schedules or webhooks — great. They do not handle "respond in 200ms" requirements. WhatsApp incoming messages, sub-second.
- iv.Anything we will need to test. Code can have unit tests. Canvases really cannot. If a flow becomes mission-critical — payment routing, refund calculations — we port it.
A pattern we keep using.
Most of our larger Operate playbooks are 80% Make/n8n with 20% small TypeScript Cloud Functions for the prompt assembly and the few sub-second hot paths. The visual layer handles the boring connections; the code handles the things that need to be tested.
Clients see the canvas. They never have to know about the Cloud Function unless they want to.
← Back to the journal