Month 3 on Make.com: The Wall Nobody Warns Solo Founders

By Lazar Milicevic · Published July 1, 2026 · 7 min read

You watched the short. Make is the friendly one, n8n is for developers, skip the learning curve. Your first scenario — Gmail trigger, filter, GPT, Telegram — works on the free plan and you feel like a wizard. Then month three lands and a real client workflow that should be four nodes is somehow twelve modules eating 40,000 ops a month. I've run both stacks in production for 14 months across paying clients. Here's exactly where the wall is, what it costs to hit it, and the operator move that keeps your automation bill flat.

The three Make.com features hidden behind "Advanced"

Every solo founder's month-three scenario bloats from 4 modules to 12 for the same reason: Make hides three primitives that n8n exposes as first-class. You don't discover them in the beginner tutorials. You discover them at 11pm when a client scenario dies silently over the weekend.

The three features, in the order they bite you:

• Iterator + Aggregator. The moment you need to process an array — email attachments, invoice line items, a list of leads from a search — you need two modules to do what n8n does with a single Loop Over Items node. Every iteration counts as an operation. Every aggregation counts as an operation.
• Error routes. In n8n, error handling is a workflow property. You set it once. In Make, every module that can fail needs its own error handler branch drawn on the canvas. Miss one and the scenario dies silently — the dashboard still says "active" while nothing has run since Friday.
• Webhook Response module. If your scenario talks back to a form, a chatbot, or another system, you need a dedicated response module wired at the exact right place in the flow. Configure it wrong and the calling system times out with no useful error.

None of this is malicious design. It's just a UI optimized for the demo, not for production. And the operations counter charges you for every one of those workaround modules.

The 47-ops-per-email math that breaks the $29 plan

Concrete case, real client audit from last quarter, generic details. Solopreneur, one Gmail inbox, wanted an AI agent that reads incoming leads, classifies them, drafts a reply, logs to Google Sheets, pings Telegram. Sounds like a four-node job.

In Make, the shipped scenario ran 47 operations per email thread. Not per email — per thread, because the iterator counts each attachment, the aggregator counts, the error branches count, and every data store lookup counts.

Here's the operations math laid out honestly:

They were on the 30k plan and hit the ceiling on day 22 of every month. Bump to the next tier, blow through that too. This is the compounding tax nobody quotes when they hand you the "Make is easier" advice.

Rebuilt in n8n on a $9/month VPS: 4 nodes, one execution per email, no per-op billing, room to 100x volume without changing the price line.

# The 4-node n8n version
Gmail Trigger → OpenAI (classify + draft) → Google Sheets (append) → Telegram (send)

That's it. No iterator because n8n handles arrays natively. No aggregator because there's nothing to aggregate. No error branches drawn on the canvas because error handling is a workflow setting.

The OAuth trap: 11 days of silent failure

Make's one-click connections feel magical until a token expires. Google rotates refresh tokens on some scopes, and when it happens Make's scenario does not email you. It starts failing silently on the trigger. The dashboard still shows the scenario as "active" because the scenario itself didn't error — the trigger just stopped seeing new events.

We had a client whose entire lead follow-up pipeline was dark for 11 days before anyone noticed. The scenario page was green. The ops counter was flat (which should have been the tell). No new leads were being logged, no Telegram pings were firing, and the sales pipeline was quietly starving.

On self-hosted n8n you own the credential store. You can wire the alerting yourself:

# n8n error workflow — fires on ANY workflow failure across the instance
# Set once in Settings → Error Workflow
# Body: Slack/Telegram post with $json.execution.error.message

One error workflow, applied globally, catches auth failures the first time they happen instead of the eleventh day. That's not a Make bug — it's an inevitable trade-off when a hosted platform manages your credentials for you.

When Make is actually the right call

I'm not here to sell a religion. Make earns its money in three specific situations, and if you're in one of them, stay:

• Fewer than 5 scenarios, none will grow. Small ops load, no iteration, no arrays. Make's UI and hosted uptime are worth the ops tax.
• Non-technical handoff. You're building for a client who will occasionally toggle scenarios on and off inside a pretty interface. n8n's editor is fine but Make's scenario view is genuinely easier for a non-builder to read.
• One-click OAuth for painful services. Some accounting, e-invoicing and legacy SaaS platforms are miserable to connect yourself. Make's connector library is a real asset there.

For everything else — every recurring client workflow with iteration, error handling, or more than 1,000 runs a week — self-hosted n8n on a $9 server pays for itself in the first month. This isn't ideology, it's arithmetic. Related reading: Make.com vs n8n: I Built the Same AI Agent in Both and Make.com Will Bankrupt You at 10K Ops — Here's the Math.

The migration bill nobody quotes

Here's the number that keeps solo founders trapped: rebuilding 30 production scenarios from Make to n8n is roughly 40 hours of engineering, assuming the person doing it already knows both platforms. If you're learning n8n while migrating, double it to 80.

Clients don't pay for a migration. They pay for the workflow they already have. You eat those 40 hours, build them into a new retainer, or stay on Make forever and let the ops bill compound. I've watched founders do all three. Only the first two end well.

That's why the right time to make the call is month three, not month twelve. Rough shape of the trap:

• Month 3: You have 4 scenarios. Rebuild is one weekend. Sunk cost is trivial.
• Month 6: You have 10-12 scenarios. Rebuild is a two-week project. Painful but survivable.
• Month 12: You have 25-30 scenarios, three clients depend on them, and the migration is a month of unbillable work you don't have.

At month twelve you are trapped by your own success. Every new scenario in Make is another rock in the backpack.

The three-question test before scenario #5

Before you build scenario number five in Make, sit down and answer three questions. This is the actual operator checklist I run for every new client onboarding.

• Will this workflow ever process arrays or loops? Attachments, line items, list of results, batch operations — anything iterated.
• Will it run more than 1,000 times a month? Count triggers × ops per run honestly, not per email but per thread.
• Does it need to survive a silent auth failure? Is a client's revenue on the other end of this scenario?

If two of the three answers are yes, start that scenario in n8n. Keep Make for the client-facing, low-volume, one-click OAuth work. Run both stacks side by side. That's what we do for every client we onboard, and it's why our automation bills stay flat while the workflows keep compounding.

A quick decision reference:

Where bizflowai.io fits in

This is the exact audit we run before we touch a client's stack. We map every scenario against the three-question test, quote the honest 40-hour migration number where it applies, and only rebuild what actually clears the payback in month one. For most SMBs we end up with a hybrid: 3-4 Make scenarios for the pretty client-facing toggles, and the heavy lifting — lead classification, invoice processing, multi-step agents — on self-hosted n8n with proper error workflows wired to Slack or Telegram. Flat monthly cost, room to scale volume 10x without a plan change, and no silent 11-day outages.

Want more like this?

I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.

Subscribe to bizflowai.io on YouTube — never miss a new tutorial.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.

Visit bizflowai.io for our services, case studies, and AI consulting.