Why I Moved My Clients Off Make.com (And What We Use Now)

Make.com Was the Obvious Choice

When clients come to me frustrated with Zapier’s pricing, Make.com (formerly Integromat) is usually the first alternative they’ve tried. And on paper, it makes sense.

Make starts at around £10/month. The visual workflow builder is genuinely more powerful than Zapier’s; you can build branching logic, loops, and complex data transformations without touching code. For connecting non-Google apps on a budget, it’s a solid tool.

So why did I end up moving clients off it?

Because most of them didn’t need to connect non-Google apps. They needed their Google Workspace to work harder. And for that, Make.com was the wrong tool doing the right job.

The Problems That Showed Up Over Time

1. The “Operations” Pricing Model Is Just Zapier With Extra Steps

Make charges per “operation”; similar to Zapier’s task model, just cheaper per unit. But the same scaling problem applies. Complex scenarios with multiple modules burn through operations quickly.

One client had a workflow that processed Google Form submissions: validate the data, check for duplicates in Sheets, create a Drive folder, generate a document from a template, email it, and log everything. That’s 6-7 operations per submission. At 50 submissions a day, they were hitting 10,000+ operations per month.

On Make’s free tier (1,000 operations), that lasted two days. On the Core plan, they were watching the counter anxiously every month.

The same workflow in Apps Script? Unlimited runs. Zero ongoing cost.

2. Google Integration Depth Is Surface-Level

Make connects to Google Sheets, Gmail, Drive, and Calendar. But the integrations are generic; they use Google’s standard APIs at a basic level.

Try to do any of these in Make:

Apply conditional formatting to a spreadsheet range
Create a custom Google Sheets formula
Manage Gmail labels programmatically
Build a custom sidebar inside Google Docs
Access Google Shared Drive files reliably
Generate a PDF from a Docs template with full formatting control

You can’t. Make’s Google modules give you read/write access to rows, basic email sending, and simple file operations. The moment you need something beyond the basics, you’re stuck, or you’re adding a custom HTTP module and writing JSON payloads by hand, which defeats the purpose of a visual builder.

Apps Script has native, full-depth access to every Google service. It’s the difference between connecting to Google and building inside Google.

3. Debugging Is Painful

When a Make scenario fails, you get an error in Make’s execution log. Sometimes it’s helpful (“400 Bad Request; invalid range”). Sometimes it’s cryptic (“Unknown error; module 7 failed”).

The problem is that Make sits between you and Google’s APIs. When something goes wrong, you’re debugging through a layer of abstraction. You can’t step through the logic, add logging, or inspect intermediate values easily.

With Apps Script, you can add Logger.log() anywhere, use the built-in debugger, check the execution transcript, and see exactly what happened at every step. When something breaks at 2am, you want to know why in minutes, not hours.

4. Vendor Lock-In (Again)

This is the same problem as Zapier, and it’s worth repeating. Your workflows live on Make’s platform. Cancel your subscription and they stop. Make changes their module for Google Sheets and your scenario breaks.

I had a client whose Make scenario stopped working after a Make platform update changed how date fields were formatted in their Google Sheets module. The data looked identical in Make’s interface, but the underlying format had shifted. It took 3 hours of debugging to find because the error wasn’t in the logic; it was in Make’s translation layer.

That doesn’t happen with Apps Script because there is no translation layer. You’re talking directly to Google.

What We Moved To

Google Apps Script. Every time.

The specifics varied by client, but the pattern was always the same:

Audit the Make scenarios; map what each one actually does, step by step
Identify what’s Google-to-Google; usually 70-90% of operations were shuffling data between Google services
Build the replacement in Apps Script; with proper error handling, logging, and monitoring
Keep Make for genuine cross-platform needs; if a client truly needs Shopify → Google Sheets, Make or Zapier is fine for that specific connection

The result? Lower costs, better reliability, deeper integration, and full ownership of the automation code.

The Migration Isn’t As Scary As It Sounds

Most of my clients assumed moving off Make would be a massive project. In practice, the average Make-to-Apps-Script migration for a Google Workspace workflow takes 2-4 hours of development time.

That’s a one-time cost that replaces an ongoing monthly subscription. For a workflow that was costing £15-30/month on Make, the migration pays for itself within the first month or two.

When Make Still Makes Sense

I’m not anti-Make. It’s a good tool for what it’s designed for:

Connecting non-Google platforms (CRMs, e-commerce, project management tools)
Rapid prototyping of cross-platform workflows
Teams with zero coding capacity who need something now

But if you’re a Google Workspace business using Make primarily to automate tasks within Google’s ecosystem, you’re paying a middleman to talk to tools you already own.

Ready to Cut the Middleman?

At Empower Automation, we specialise in migrating Google Workspace automations from Make.com and Zapier to native Apps Script. No monthly fees, no operation limits, no abstraction layers.

Book a free 15-minute automation audit →

Send us your Make scenario links and we’ll tell you which ones are worth migrating, and which ones should stay where they are.

Nicola Berry is the founder of Empower Automation, based in Falkirk, Scotland. Specialist in Google Apps Script for businesses that want to own their automation.