I retired two paid automation subscriptions and replaced them with scripts the team could read and change. This is the reasoning, the migration method, and the cases where I would have kept paying.
I retired two paid automation subscriptions in a live agency and replaced them with scripts the team could read and change. This is what drove that decision, and when I would not make it.
To be clear up front: connector platforms are genuinely good products and I still use them. This is not a rant about SaaS. It is about which automations belong on rented rails and which do not.
Three properties that eventually bite
They price by volume. This is the structural problem. The automation that saves you the most time is, almost by definition, the one that runs most often. Under per-task or per-operation pricing, that is also the one that costs the most to keep. Your most valuable automation is your most expensive line item, which is exactly backwards.
It gets worse with multi-step workflows. A ten-step scenario counts as ten operations per run. An automation that creates twenty-nine tickets counts as twenty-nine actions. Polling triggers consume operations whether or not anything happened.
They constrain the logic. Anything conditional beyond a certain complexity becomes an unreadable chain of branches in a visual builder. A condition that takes three lines in a script becomes six nested blocks that only their author can follow, which is a maintenance problem wearing a friendly interface.
They are a dependency nobody owns. When the person who built it leaves, the account, the billing and the logic leave with them. I have seen a business unable to modify a critical workflow because it lived in a personal account nobody else could access.
A load-bearing automation should belong to the business, not to a login and a billing relationship.
When to keep the connector
Genuinely often, and I want to be even-handed here.
Keep it when the automation is low volume. Something that runs twenty times a month costs almost nothing and is not worth engineering time.
Keep it when it joins two third-party services you do not control. This is what connector platforms are actually excellent at. Writing and maintaining your own integrations against two external APIs is real ongoing work, and someone else doing it for you is worth paying for.
Keep it when nobody available can maintain a script. An automation that works and costs money beats one that broke and nobody can fix. Be honest about who is around in twelve months.
Keep it while you are still figuring out what to build. Prototype in the connector, then move it once the logic has stopped changing.
How to do the migration
1. Inventory what you actually run
List every automation, what triggers it, how often it fires, and what it costs. Most teams doing this for the first time find at least one automation nobody remembers building and one that has been failing silently.
2. Rank by volume times criticality
High volume and load-bearing goes to the top. Low volume stays where it is. Do not migrate everything; migrating a rarely-used automation is engineering time spent for no return.
3. Rebuild one, in parallel, without switching anything off
Run both for a fortnight and compare outputs. This is the step people skip and it is the reason migrations go badly. You will find behaviour in the original that nobody documented.
4. Write the failure notification before the happy path
A silent failure is worse than no automation, because everyone now trusts a thing that stopped working. Every script I run reports its own errors to a channel a person reads.
5. Leave a comment saying why, not what
The code will be obvious in six months and the reasoning will not. One line explaining why the threshold is seven days rather than five saves whoever comes next, which is usually you.
6. Cancel the subscription only after a full cycle
If it runs monthly, wait a month. Cancelling early to book the saving is how you discover the edge case that only fires at month end.
What the alternatives cost
| Option | What it costs | Honest trade-off |
|---|---|---|
| Zapier | Per task. Free tier is very limited; paid plans scale with task volume, and multi-step workflows multiply the count. | The widest integration library by far and the fastest to a working version. Cost climbs steeply on high-volume workflows. |
| Make | Per operation. Every module action counts, including polling checks that find nothing. | Better value than per-task pricing for complex visual logic. Operation counts are easy to underestimate. |
| n8n | Per workflow execution, or self-hosted. | Self-hosting removes the per-run cost and adds upgrades, backups, monitoring and incident response to somebody's calendar. Free like a puppy is free. |
| Google Apps Script | Free with Google Workspace. | No per-run cost and the code is yours. Six minute execution limit per run, and daily trigger runtime quotas, so long jobs need to be chunked. |
| ScriptRunner or similar inside your work tracker | Per-user, on top of existing seats. | Unlimited executions and deep access to the tool's own data model. Cost scales with headcount regardless of usage. |
What it is actually worth
The saving is arithmetic you can do yourself in ten minutes, and it will be more honest than anything I could quote.
Take your current monthly automation spend. Estimate the engineering time to rebuild the top two automations. Divide. That is your payback period. For the two subscriptions I retired, the rebuild was days and the saving was ongoing, which made it obvious. If your rebuild is weeks and your subscription is modest, the answer is to keep paying.
The wider context is worth knowing: Zylo's 2025 SaaS Management Index, drawn from its customers' aggregated licence and spend data, reported average annual waste on unused software around $21 million per organisation, up 14.2 percent year on year, with roughly 53 percent of licences unused. Zylo sells software asset management, their data skews heavily enterprise, and those absolute figures mean nothing for a twenty-person business. The useful part is the rate, and the direction, both of which travel.
How it breaks
The script becomes its own single point of failure. If one person wrote it and only that person understands it, you have swapped a vendor dependency for a person dependency, which is worse. Readable code and a short comment block are the entire mitigation.
Nobody notices it stopped. Connector platforms have failure notifications built in. Yours does not until you write it, and that is the first thing to build.
Quotas bite at the wrong moment. Apps Script has a six-minute execution limit and daily trigger runtime caps. Discover those during a test, not during month-end reporting.
How to tell whether it worked
Monthly automation spend, obviously. But also the number of people who can modify each automation, which should be more than one, and mean time to notice a failure, which should be minutes rather than the day somebody asks why a report never arrived.