Zapier, Make or Custom Automation? When No-Code Tools Stop Scaling

Custom automation, meaning software written specifically around the way your business works, is where some growing firms end up after a few years with Zapier or Make. It is not always the right next step, though. No-code tools are genuinely good at what they do, and plenty of businesses never need anything more.

This guide is for the point in between: when your automations work, mostly, but the monthly bill keeps rising, nobody quite understands how the Zaps fit together and errors are discovered by customers rather than staff. It explains how no-code automation is priced, the signs that it is reaching its limits, what the alternative involves and how to move without disrupting the business. We build operational automations for a living, so we will be honest about when you do not need us.

What Zapier and Make do well

Zapier and Make are no-code automation platforms. You choose a trigger, such as a new form submission or a paid invoice, and one or more actions that follow, such as creating a contact, sending an email or adding a row to a spreadsheet. Zapier’s pricing page says it connects to more than 9,000 apps, and Make covers a broad range of popular business software too.

Their strengths are real:

• Speed. A simple automation can be running in an afternoon, without a developer.
• Low starting cost. Both have free plans with small monthly allowances, and entry-level paid plans cost far less than a day of development.
• Ownership by the team. The person who understands the process can often build and adjust the automation themselves.
• Maintained connectors. When a connected app changes its API, the platform usually updates the connector, not you.

For low-volume, linear tasks, such as posting new enquiries into a team chat or copying form entries into a spreadsheet, no-code automation is usually the right answer, and custom automation would be overkill.

How no-code automation is priced

Understanding the pricing model explains a lot about when these tools stop making sense. Both platforms charge by usage rather than by the number of automations you build.

Zapier: tasks

Zapier counts tasks. Its help article on how task usage is measured explains that each successful action step uses a task, while triggers and built-in tools such as Filter, Formatter, Paths and Delay do not. The free plan includes 100 tasks a month and two-step Zaps that check for new data every 15 minutes. Paid plans add multi-step Zaps and faster checking, and allowances run from hundreds to millions of tasks a month. If you reach your limit, Zapier holds further Zap runs until your billing cycle resets, you upgrade or you turn on pay-per-task billing.

Make: credits

Make bills in credits. According to Make’s help centre page on how credits work, most non-AI modules use one credit per operation, while some AI features use more depending on the tokens processed. If you run out before your billing cycle ends, you can upgrade, buy extra credits or turn on automatic top-ups.

Why volume matters

Under both models, cost grows with the number of steps multiplied by the number of times the automation runs. As an illustrative calculation, an order process with five action steps that runs 40 times a working day uses around 4,400 tasks over a 22-day month. Add a second process of the same size, or a busy season, and the plan tier needed can climb quickly. That is fine when the automation saves more than it costs, but it means no-code automation gets more expensive precisely as your business grows.

Signs your no-code tools are reaching their limits

None of these signs means you must move away from Zapier or Make. Two or three together usually mean it is time to look properly at the options.

• The bill keeps rising with volume. You are moving up task or credit tiers every few months, and the same work would cost far less as a fixed-cost service.
• Nobody understands the whole picture. Dozens of Zaps or scenarios trigger each other, some built by people who have since left, and changing one breaks another.
• Errors are found by customers. A failed step means an order confirmation never went out or an invoice was never created, and you hear about it from the customer.
• The logic has outgrown the editor. Paths within paths, lookup tables, storage steps and code steps are being used to imitate a database or an application.
• Timing matters. Scheduled checks mean a delay of minutes between an event and the response, and some processes cannot wait.
• Data is being held in odd places. Spreadsheets and storage steps exist only to remember what the automation has already done.
• One person holds it all together. If they are off sick, nobody can fix a failed run.

The underlying issue is usually the same: a set of automations has quietly become a piece of business software, without the structure, testing and monitoring that software normally has.

What custom automation actually involves

Custom automation is code written for your processes, running on a server or cloud platform you control. Instead of going through a no-code platform, it talks directly to each system’s API and receives webhooks when things happen. It usually has its own small database to remember what it has done, logs every action and alerts a named person when something needs attention.

Typical custom automation projects include:

• turning completed jobs into invoices in Xero or QuickBooks, with your exact rules for pricing, tax and customers;
• allocating new jobs to engineers based on location, skills and availability;
• sending customers updates at each stage of an order or job;
• syncing stock between an online shop, a warehouse system and a marketplace;
• producing a daily exceptions report so that the office deals with problems rather than routine work.

Accounting connections are a common example, and our guide to connecting Xero or QuickBooks to your website and CRM explains how they work in more detail.

Comparing the options honestly

Neither approach is better in every respect. These are the trade-offs that matter most:

• Cost model. No-code tools are cheap to start and charge more as usage grows. Custom automation costs more up front, then mostly fixed amounts for hosting and maintenance, whatever the volume.
• Flexibility. No-code tools do what their connectors allow. Custom code can use everything an API offers and apply any business rule you can describe.
• Reliability. Both can be reliable. The difference is control: custom code can retry, queue and recover in exactly the way your process needs, and its tests can be rerun before every change.
• Speed of change. Adjusting a Zap takes minutes. Changing custom code needs a developer, although well-built code is quick to change too.
• Ownership. With custom automation you should own the code and the hosting accounts. With no-code tools, your automations live inside someone else’s platform.
• Maintenance. No-code platforms maintain their connectors. With custom code, someone has to update it when a connected API changes.

What custom automation costs

Treat these figures as a rough guide to typical UK market prices, not a quote. A single, well-defined custom automation that connects two systems with good APIs is often priced in the low thousands of pounds. Larger projects that replace a web of automations, include their own interface or connect older systems can cost considerably more.

What drives the price:

• how many systems are involved, and how good their APIs are;
• how many steps, rules and exceptions the process has;
• whether the automation needs screens for staff, or runs entirely in the background;
• how much existing data needs moving or tidying first;
• ongoing hosting, monitoring and maintenance.

To compare fairly, add up what you spend now: the subscription, the time staff spend fixing failed runs and the cost of the mistakes that slip through. A custom build that costs more than a year of Zapier but removes most of those hidden costs can still be the cheaper option over three years. Equally, if your Zapier bill is modest and nothing goes wrong, keep it.

The middle path: mixing both

It is rarely all or nothing. Many businesses do well with a hybrid:

• keep no-code automation for simple, low-volume tasks that staff like to adjust themselves;
• move the high-volume or business-critical process, such as order handling or invoicing, into custom automation;
• have the custom service send webhooks that a Zap can pick up for minor follow-on tasks, such as posting a notification.

Email marketing is a good example. Tools built for it handle sequences and segments well, as our guide to email marketing automation for small businesses explains, and there is no need to rebuild that. The custom part might simply make sure the right customer data reaches the email platform at the right time.

An illustrative example: an equipment hire firm

To make this concrete, here is an illustrative example. The business is made up, but the pattern is a common one.

An equipment hire firm started with a single Zap that copied website bookings into a spreadsheet. Three years later it has more than twenty Zaps: bookings create jobs, jobs create invoices in Xero, deposits are matched from Stripe, reminders go out before collection dates, and several spreadsheets keep track of which steps have already happened. The firm has moved up Zapier’s task tiers twice in a year, and the office manager spends part of every Monday checking for failed runs.

A review shows that two processes, bookings to invoices and deposit matching, account for most of the task usage and almost all of the errors. Those two are rebuilt as custom automation with a small database, proper logging and a daily exceptions email. The reminder emails and team notifications stay in Zapier, where the office manager can still adjust them. The firm’s no-code spend falls to a lower tier, Monday mornings are freed up, and when something does fail, the office manager is told exactly what and why.

How to move without disrupting the business

1. List every automation. Record what triggers it, what it does, how often it runs, what it costs and who relies on it.
2. Write down the real rules. Many rules live only inside filter steps and people’s heads. Capture them in plain English before any code is written.
3. Prioritise by volume and risk. Start with the process that costs most or causes most errors, not the easiest one.
4. Run old and new side by side. Let the new automation process real events in a test mode and compare its results with the existing Zap before switching over.
5. Switch off cleanly. Turn off the old automation once the new one is proven, so the same action does not happen twice.
6. Agree support. Decide who receives alerts, who fixes problems and how changes will be requested.

The same thinking applies to automation in software development itself, where repeatable, tested processes replace manual steps, as we discuss in Automation: Streamlining Development Processes. It is also why we built automations into Ops Pilot CRM, our own platform for agencies and freelancers, which combines email campaigns and automations with contacts, projects and tasks, invoicing and branded client portals.

Questions to ask before you commission custom automation

If you do decide to move part of your automation into code, these questions will help you compare developers and avoid surprises later:

• Which of our current automations would you move, which would you leave alone, and why?
• How will failures be detected, retried and reported, and who will be told?
• Where will the code run, where will our data be stored, and how does that fit with our UK GDPR obligations?
• Will we own the code and the hosting accounts outright?
• How will changes be tested before they go live?
• What will hosting, monitoring and support cost each year, and what happens when a connected app changes its API?

The same questions are worth asking of your current set-up. If nobody can say where your Zaps send customer data, or who is told when a run fails, that is a reason to tidy things up whichever route you choose.

Custom automation: common questions

Is there anything wrong with Zapier or Make?

No. They are well-established platforms that suit a huge number of businesses. The question is not whether they are good, but whether a particular process has outgrown what a no-code tool is designed for.

Can we keep some of our Zaps?

Yes, and often you should. A hybrid set-up keeps the flexibility of no-code tools for simple tasks while moving critical, high-volume work into code you control.

Who looks after custom automation once it is built?

Usually the developer who built it, under a support agreement covering monitoring, fixes and updates when connected systems change. You should also own the code and hosting accounts, so you can move to another developer if you ever need to.

Will custom automation be more reliable?

It should be, if it is built properly, because it can be designed around your process with tests, logging and alerts from the start. Badly built custom code can be just as fragile as a tangle of Zaps, so ask any developer how they handle failures before you commit.

The bottom line

No-code tools are an excellent way to start automating, and for many businesses they are all that is ever needed. When the bill climbs with every busy month, failures reach customers and nobody understands how it all fits together, custom automation for your core processes is worth a serious look, ideally alongside the simple automations that still work well.

If you are not sure which side of that line you are on, tell us what you have automated so far or call us on 01482 212499. We will tell you honestly whether to keep what you have, tidy it up or move the critical parts into custom code.