⚖️ n8n vs. Make vs. code
A base that orchestrates your workflow determines your flexibility ceiling and your maintenance floor. There are three paths: n8n (low-code, self-hosted, highly flexible), Make (visual, SaaS, quick to get started) and code (full control, full maintenance).
✓ Start simple when
- ✓The workflow fits the tool’s built-in connectors.
- ✓You want to validate the idea quickly, without infrastructure.
- ✓The logic is straightforward, with no exotic transformations.
✗ Move to code when
- ✗You hit SaaS execution or licensing limits.
- ✗A connector is missing, and the glue becomes too fragile.
- ✗The logic turns into a tangle of nodes that’s impossible to maintain.
Fast, SaaS, visual.
Flexible, self-hosted.
Maximum control and maintenance.
The wrong choice costs you later.
🧠 When to use an LLM and which model
First: the task needs from an LLM? If a rule, regex, or IF can solve it, use those—they’re cheaper and deterministic. If it requires language interpretation, choose the model based on the cost × capacity: small and inexpensive for classification, large and expensive for complex reasoning.
Small / inexpensive model
Classify, extract fields, answer yes/no, label sentiment. Narrow, high-volume tasks where every cent per call matters.
Medium model
Summarize, draft replies, follow multi-step instructions. The default balance for most automations.
Large / expensive model
Complex reasoning, analysis of long documents, high-stakes decisions. Use it only where the extra capability is worth the cost.
💡 Practical tip
Start with the the cheapest model that works and scale up only if the quality doesn’t meet the metric. The opposite—starting at the top "to be safe"—burns through your budget and hides how much capacity you really need.
Can a rule solve this without an LLM?
Match the task to the model.
Cost per token × scale.
Only if the metric requires it.
📚 RAG: your own knowledge in context
The model only knows what it saw during training. When the automation depends on information that only exists in your company — policies, catalog, customer history—you use RAG: retrieves the relevant excerpts from your knowledge base and injects them into the prompt, grounding the AI in your source of truth instead of letting it make things up.
📐 When RAG Is Worth It (and When It Isn’t)
- •Applies: your own knowledge, changes frequently, too large to fit in the prompt.
- •Doesn’t count: the information fits directly in the prompt, or the model already knows it (general knowledge).
- •RAG adds infrastructure (vector + search) — only take on that cost when it solves a real problem.
Search before generating.
Search by meaning.
Reduces hallucinations.
There is proprietary knowledge.
🔌 MCP and tool integration
When AI needs to act — read a file, query a database, call an API— the MCP (Model Context Protocol) offers a standardized way to connect AI to these tools, without writing different glue code for each one. It's what turns the model from "responds with text" into "uses tools."
🔧 What MCP standardizes
- •How AI discovers which tools are available and what each one does.
- •How it invokes a tool and gets the result back.
- •Reuse: the same MCP server works for any compatible client.
💡 Practical tip
Not every automation needs MCP. If the workflow already orchestrates the steps (n8n determines the order), you can call APIs directly. MCP shines when it’s the AI itself that determines which tool to use and when — that's when standardizing access pays off.
Standardized access.
AI that acts, not just talks.
One server, many clients.
AI chooses the tool.
🔗 APIs, webhooks, and databases
The plumbing of automation. API: you request data when you want it. Webhook: the system notifies you when something happens. Database: you store and look up state between executions. Supabase is a practical example that combines a database + API + authentication in one package.
✓ Use webhook when
- ✓You want to react as soon as something happens.
- ✓The event is unpredictable (a client submits a form).
- ✓Asking “any updates yet?” would be a waste.
✓ Use API/polling when
- ✓You need to fetch data on demand.
- ✓The source system doesn't offer a webhook.
- ✓A fixed check schedule does the job.
🗄️ When you need a database
- •The automation needs to remember something between executions (state, history).
- •You need to avoid processing the same item twice (duplicate control).
- •Supabase provides a Postgres database + REST API + auth with minimal setup.
Pull: you request it.
Push: it notifies you.
Stores state.
Database + API + auth.
🎚️ Decision criteria and trade-offs
Every stack choice replaces one thing with another. An explicit set of criteria — cost, delivery speed, maintenance, control, scale, vendor dependence — forces you to justify each decision instead of following trends or habits. And it gives you a good argument in front of the client.
🧾 Trade-Off Matrix (Template)
⚠️ Attention
Watch out for lock-in: choosing a tool that locks in your data and workflows makes it harder to leave later. And remember that the newest model or the hottest tool is rarely the right choice — simple wins when it's a tie.
Every choice involves a trade-off.
Explicit and weighted.
Think about the cost of leaving.
Wins in a tie.
🧰 Module Summary
Next Module:
3.3 · Prompt and decision logic design — the brain of the automation.