Every conversation about automation tools eventually turns into a cost question. "Is Zapier worth it at this scale?" "Should we just use Apps Script?" "Make.com or n8n?" Most of the comparison content on the web is written by vendors or affiliates — it doesn't have actual project data behind it.
This page is built from 120+ automation projects we've delivered. The tool split, what clients were actually paying before and after, how long builds take in practice, and the failure modes we've seen in production — things that don't show up in feature comparison tables.
The Project Breakdown
Here's how our 120+ projects split by primary tool used:
Apps Script is the majority because most small and mid-sized businesses run on Google Workspace. When the data already lives in Sheets and Drive, Apps Script is free, integrates natively, and has no per-run cost ceiling. The Zapier and Make.com projects were mostly clients who came to us already on those platforms — either to extend what they had, or to migrate off them after costs got uncomfortable.
What Builds Actually Cost
Our average build is around 5 hours per automation at $25/hr — a typical single automation costs ~$125 to build. More complex multi-system workflows run 10–20 hours; simple triggers are 2–3 hours.
That's a one-time cost. No monthly fee on top of it. After the build, the automation runs — on Apps Script for free, or on whatever platform the client is already paying for.
Platform Cost Reality
| Tool | Platform Cost | Per-run cost? | Best for |
|---|---|---|---|
| Google Apps Script | Free | None | Google Workspace-heavy businesses, recurring tasks, any team where platform costs are a constraint |
| Zapier | ~$20–$500+/mo | Yes — per task | Quick SaaS-to-SaaS connections, non-technical teams who need to maintain it themselves |
| Make.com | ~$9–$200+/mo | Yes — per operation | Complex multi-step visual logic, teams comfortable with flow builders |
| AppSheet | ~$5–$10/user/mo | No (flat per user) | Mobile field apps, form-driven workflows, teams that need an app without custom dev |
| n8n (self-hosted) | Near zero (hosting only) | None | Technical teams wanting full control, high-volume workflows |
| Custom full-stack | Hosting only | None | Real-time needs, zero fault tolerance, scale that no tool handles cleanly |
The per-run pricing on Zapier and Make.com is the part that surprises clients most. It's easy to start on a free tier and not notice the cost growing as the workflow runs more often. A business processing a few hundred records a day can burn through task limits fast — and the next plan tier often jumps significantly in price. The same workflow in Apps Script has no per-run cost, ever.
Break-Even on Migration to Apps Script
The calculation clients want to do: "We're paying $X/month on Zapier. What does migration actually cost, and when does it pay off?"
Break-Even at $125 Build Cost
Build cost ÷ monthly savings = months to break even. After that, the savings are permanent.
For anyone paying over $100/month on Zapier or Make, migration typically pays for itself before the next billing cycle. We've had clients break even in their first week.
Get the one-page cheat sheet
The decision framework, failure modes, and break-even table — in a printable format.
No spam. Unsubscribe any time.
What the Tools Don't Tell You
These are patterns we've seen across 120+ projects — the things that don't appear in feature tables.
When a Zap fails — bad auth token, an upstream API changes its response format, a rate limit gets hit — it fails quietly. No alert, no email, nothing. You find out days later when someone notices a downstream spreadsheet hasn't updated, or a report is missing rows. We've had clients come to us after losing a week of data because a workflow stopped running and nobody knew. If you're running anything business-critical on Zapier or Make, build your own alerting on top of it — you can't rely on the platform to tell you when something breaks.
Apps Script has execution time limits and isn't designed for sub-second response. Zapier and Make introduce latency of seconds to minutes per run. If your automation needs to respond in milliseconds, process thousands of records concurrently, or guarantee uptime — none of these tools are the answer. The right call is a custom solution. Most businesses don't actually need those requirements, but when they do, using a no-code tool is the wrong starting point and creates technical debt that's painful to unwind later.
AppSheet is genuinely good at what it does: data-driven apps, field team workflows, form-based processes. But its UI customization is limited by design. You can control layouts and views to a degree, but if a client has a specific brand, a non-standard interaction, or any UI requirement beyond AppSheet's standard components — it won't get there. We've learned to scope this upfront. If the client cares equally about how it looks and how it works, AppSheet is the wrong tool regardless of how well it fits the data model.
6-minute execution cap. No persistent server process. Daily quota limits on API calls. These trip up first-timers building their first script. After 60+ projects in it, we've worked around nearly all of them: chained time-based triggers to extend execution past 6 minutes, ScriptProperties and PropertiesService to persist state across runs, batching to stay under quota limits, LockService to prevent race conditions when multiple triggers fire simultaneously. The language is the platform — and knowing the patterns makes most of the "limitations" manageable.
The AppSheet Insight Most Builders Miss
This one took a few projects to figure out, and it makes a significant difference in how snappy an AppSheet app feels.
AppSheet has two types of formula evaluation. App formulas run locally on the device — they evaluate instantly as the user interacts, with no server roundtrip. Computed columns and workflow rules run on the server, which means a sync cycle fires, data goes to the server and comes back, and the user waits.
Running totals, derived fields, conditional displays — anything the user sees in real time should use App formulas, not server-side computed columns. If an AppSheet app feels sluggish, the first thing to audit is how many server-side evaluations are chained per interaction. We rebuilt one client's inventory app almost entirely around App formulas and it went from feeling slow to feeling native — same data model, same backend, just the computation layer moved to the device.
When to Use Which Tool
Use Google Apps Script when:
- The business runs on Google Workspace and data lives in Sheets, Drive, or Gmail
- Ongoing platform costs aren't sustainable
- The logic is complex enough that visual flow builders become hard to maintain
- You want full control over error handling, retries, and alerting
Use Zapier or Make.com when:
- You need connections to many SaaS tools quickly — both have 1,000+ integrations
- The team maintaining it isn't technical and won't be writing code
- Volume is low enough that per-task costs stay manageable
- Speed of setup matters more than long-term cost
Use AppSheet when:
- You need a mobile app for field teams or on-site use
- The workflow is form-driven and data-centric
- UI customisation isn't a primary requirement
- Data already lives in Google Sheets
Consider a custom solution when:
- Real-time or near-real-time processing is a requirement
- Volume is high enough to make per-run platform costs painful
- Uptime and fault tolerance genuinely matter — data pipelines, payment flows, customer-facing triggers
- Workflow complexity has outgrown what visual tools handle cleanly
Not sure which tool fits your process? We'll look at what you're actually trying to automate and give you an honest answer — including if it's something you don't need to hire anyone to build.
Talk to us