Which platform will you use — Make, n8n or Zapier?

It depends on your volume, because the three charge for different things. Zapier counts tasks, meaning every action inside a run. Make counts operations, meaning every module inside a run. n8n counts whole executions, so a forty-step workflow costs the same as a three-step one. A high-volume workflow that is affordable on n8n can be an order of magnitude more expensive on Zapier for identical work. We work out the monthly figure on each before choosing, and you see that comparison.

Can you build it from a written description of the process?

We would rather not, and the reason is consistent. What clients describe is the process as it is supposed to work. The process as it actually runs contains two or three branches that start with the phrase — and sometimes what happens is. Those branches are where the project breaks in week three. A recorded screen share of the work being done once, at normal speed, prevents it.

What happens when something breaks at three in the morning?

An alert goes to a channel someone already looks at — Telegram, WhatsApp or Slack, not email. It names the workflow, the exact step, the real error text, the specific record it failed on, and what to do about it. Alongside that, failed records go to a dead letter sheet so nothing is silently lost, and a heartbeat check catches the worse case where the automation is not running at all and therefore producing no errors.

Do the accounts go in my name or yours?

Yours. Every platform account, every connection, every card is in your name with us added as a user. If we ever stop working together, nothing switches off and nothing has to be rebuilt. We decline the reverse arrangement even when clients offer it, because it puts a live part of your business on someone else's billing.

What happens after handover?

You get a screen recording of the system running including what an alert looks like, a one-page document per workflow saying what it does and what to do if it stops, and a shared alert channel. Thirty days of support are included. After that a monthly care plan is available — platforms change their APIs, tokens expire and sites move, so somebody has to be watching.

How many workflows is a typical project?

Usually three to eight rather than one. Clients describe the job as a single connection — Shopify to accounting, say — and the connection is often the smallest part. The work that follows the connection is where the actual hours are, and where the actual value is.

Automation & No-Code

Workflow automation with Make, n8n and Zapier

The repetitive work in your business rebuilt as automations that run without supervision — and that tell you when they stop.

From: $400–$6,000
Typical time: 1–5 weeks
Usually bought by: Every SME

What this actually solves

Someone in your business spends a large part of every day moving the same information between the same places. They open an inbox, read an order, type it into a spreadsheet, type it again into accounting software, build a list, and send a batch of messages in the evening. None of that is judgement. It is transcription, and people are unreliable at transcription in a specific way — they are almost perfect for two hours and then they are not.

That is the version that brings people to this page, and it is the least valuable one. Two others sit underneath it. The first is missed work: an order arrives on a channel nobody was watching, and nobody finds out until the customer calls. The loss there is not an hour of labour, it is a customer. The second is response speed. If a competitor replies within minutes and you reply the following morning, you lose deals you never knew you were in. That one connects directly to revenue, which is why it changes what the work is worth.

There is a harder truth underneath all three, and it decides whether this is worth buying. While work is manual, a human is watching it. When only five orders come in, they notice and ask why. Automate it, and they stop watching — they trusted the system. If that system then dies quietly, nobody asks, because the person who would have asked was the one you removed from the loop. An automation that stopped running without telling anyone is worse than no automation at all. Most of what we build, and most of what separates a working system from a demo, exists to make sure that cannot happen.

What we do, and in what order

Watch the work happen, once, recorded. Screen share, normal speed, nothing skipped or tidied. We are looking for three things — every copy-and-paste, every pause where a person is deciding something (that becomes a filter or a router), and every sentence beginning "and sometimes what happens is". That last one is where the risk lives. Half a day to a day.
Write the process down and get it confirmed in writing. A plain-language SOP: each step, who does it, how long it takes, which software it touches. You correct it, and you sign it off. That document is usually the first written record of what the process actually costs you in hours, and it is also what settles scope arguments later. Half a day to a day.
Map each workflow and choose the platform on arithmetic. One trigger per workflow, then steps, then outcome, with every decision point marked. Then the platform choice, calculated from your monthly run volume against each platform's counting model, with the resulting monthly operating cost written down so it is your decision and not a surprise on a bill. Half a day.
Build in small pieces, checking the output of each. Day one is the trigger plus one step, run and inspected. Then the next step. We read the actual JSON coming out of each module rather than assuming it is what the documentation implies. Three days to three weeks, depending on how many workflows there are.
Wire the failure handling. This is not a phase we get to if there is time. Error handler routes on the modules that can fail, alerts written so they are actionable rather than "something went wrong", duplicate suppression keyed on a unique id, a dead letter sheet for records that could not be processed, a heartbeat ping so a workflow that has stopped entirely still raises an alarm, and a run log row for every execution. One to two days.
Feed it dirty data, then break it deliberately. Real-world mess: an order with no quantity, two orders in one message, a message that is actually a question, a customer name not in the list, a photo with no text, a quantity written as "two dozen". Then the fire drill — we rotate a key, rename a column, and switch a scenario off, and confirm the alerts actually fire. If nothing happens, the work is not finished. One day.
Hand over. Screen recording, one-page document per workflow, shared alert channel, and thirty days of support. Half a day.

Tools, so you know what you are buying: Make, n8n or Zapier for the workflows themselves, Airtable or Google Sheets for data your team can actually see, Telegram or Slack for alerts, and Healthchecks.io for the heartbeat.

What moves the price

How many workflows there actually are. One workflow sits at the bottom of the range. Eight sits near the top. The count is rarely what the first conversation suggests, which is why the SOP comes before the quote rather than after it.

Volume, and therefore platform. Twenty runs a day and five thousand runs a day are different engineering problems and different monthly bills. High volume also forces choices about batching, rate limits and where state is stored.

What it costs you when the work stops. This is the one that moves the number most. Two projects can take identical effort — an internal report and an order intake pipeline — and be worth three times different amounts, because one failing means a report is late and the other failing means customers leave without telling you. We ask what breaks first if this work does not happen for a week, and the answer sets the price.

What usually goes wrong

The trigger sees more than the process you described. A written description gives us one path: an order arrives, it gets entered. The inbox that trigger actually watches carries other things too — a price enquiry, someone asking whether yesterday's order is still confirmed, a payment screenshot with no text in it at all, a complaint about last week's delivery. Each of those needs its own router branch or it lands in your system as a malformed order. The screenshot is the one that bites: the module downstream is built to read text fields and receives a payload that has none, so it fails on a shape nobody mentioned, because nobody thinks of it as part of the process. Watching the work and writing the SOP is what surfaces those branches before anything is built around them.

Treating the failure handling as an optional extra. The build works on the day, so the alert route, dead letter sheet and heartbeat start to look like something to add later. The platforms will not cover that gap for you. Zapier emails whoever owns the account when a Zap turns itself off, Make simply stops once the month's operations are used up, and n8n raises nothing at all unless an error workflow was wired to catch it. Worse, an automation that is not running produces no errors, because the error handler only fires when the workflow fires — so every screen stays calm while orders stop arriving. That is why this sits inside the price and inside the build rather than being an option you can decline.

Retries quietly create duplicates. Retrying is the correct response to a temporary failure, and it is also how a customer receives the same confirmation message three times, or how one order becomes three rows in accounting. Every incoming item needs a unique handle — a Telegram message id, a Gmail Message-ID, a Shopify order id — checked against a data store before anything happens and written back after. Two extra operations per run, and it prevents the class of embarrassment that is visible to your customers.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

Which platform will you use — Make, n8n or Zapier?: It depends on your volume, because the three charge for different things. Zapier counts tasks, meaning every action inside a run. Make counts operations, meaning every module inside a run. n8n counts whole executions, so a forty-step workflow costs the same as a three-step one. A high-volume workflow that is affordable on n8n can be an order of magnitude more expensive on Zapier for identical work. We work out the monthly figure on each before choosing, and you see that comparison.
Can you build it from a written description of the process?: We would rather not, and the reason is consistent. What clients describe is the process as it is supposed to work. The process as it actually runs contains two or three branches that start with the phrase — and sometimes what happens is. Those branches are where the project breaks in week three. A recorded screen share of the work being done once, at normal speed, prevents it.
What happens when something breaks at three in the morning?: An alert goes to a channel someone already looks at — Telegram, WhatsApp or Slack, not email. It names the workflow, the exact step, the real error text, the specific record it failed on, and what to do about it. Alongside that, failed records go to a dead letter sheet so nothing is silently lost, and a heartbeat check catches the worse case where the automation is not running at all and therefore producing no errors.
Do the accounts go in my name or yours?: Yours. Every platform account, every connection, every card is in your name with us added as a user. If we ever stop working together, nothing switches off and nothing has to be rebuilt. We decline the reverse arrangement even when clients offer it, because it puts a live part of your business on someone else's billing.
What happens after handover?: You get a screen recording of the system running including what an alert looks like, a one-page document per workflow saying what it does and what to do if it stops, and a shared alert channel. Thirty days of support are included. After that a monthly care plan is available — platforms change their APIs, tokens expire and sites move, so somebody has to be watching.
How many workflows is a typical project?: Usually three to eight rather than one. Clients describe the job as a single connection — Shopify to accounting, say — and the connection is often the smallest part. The work that follows the connection is where the actual hours are, and where the actual value is.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about Workflow automation (Make / n8n / Zapier) All Automation & No-Code services