DEV Community: 2pizza.team

Automating Shopify Order Processing: The Full Workflow

2pizza.team — Thu, 01 Oct 2026 13:00:10 +0000

TL;DR: three to five days, $1,500-2,500, $9-16/month to run. Worth it from roughly 20 orders a day. The whole difficulty is in four places: duplicate webhook delivery, partial fulfilment, failed payments, and returns. Everything else is wiring modules together.

Shopify gives you the store. It does not do the work behind it. Every order still needs someone to check stock, tell the warehouse, produce a packing slip, get a tracking number in, and tell the customer. At five orders a day you cope. At fifty you do not.

This is the deep version, covering order processing only. If you want the wider picture across orders, support and reordering, the full store guide covers that at a higher level and this goes underneath it.

The happy path, which is the easy 20%

Shopify fires a webhook on a new order. Your scenario catches it and runs: check stock, notify whoever packs with the order and instructions, generate the packing slip, create the shipment with the courier and pull the tracking number, send the customer a real tracking email. Order to warehouse notification in under two minutes.

Building that takes a day. Building the version that is still correct in month six takes the rest of the week, and the difference is entirely in the four problems below.

Problem 1: webhooks arrive more than once

This is the one that costs real money and almost nobody builds for it. Shopify guarantees at-least-once delivery, not exactly-once. If your endpoint is slow or returns an error after doing half the work, the same order is delivered again.

Without a guard, that is a second pick instruction to the warehouse, a second confirmation email to the customer, and sometimes a second shipping label you paid for. It does not look like a bug, it looks like a strange busy day.

The fix is small and must come first in the scenario: record the Shopify order ID before doing anything else, and on every delivery check whether that ID has already been handled. If it has, stop. This makes retries safe, which in turn makes it safe to retry deliberately when a downstream API is flaky.

Related and just as important: answer the webhook fast and do the work afterwards. A scenario that spends forty seconds calling a courier before responding will be re-delivered by Shopify while it is still working. Acknowledge, then process.

Problem 2: orders do not ship all at once

An order with three items where one is out of stock is not an edge case, it is Tuesday. If your automation treats an order as a single unit, it will either hold the whole thing until everything is available, or mark the order fulfilled when the first part ships.

Both are bad for different people. The first annoys a customer who would happily take two items now. The second tells them their order shipped when half of it did not, which produces a support ticket and a refund request.

Decide the policy explicitly before building: ship what is available and track the remainder as a separate fulfilment, or hold, with a rule for how long. Then build it. The default of not having a policy is what generates the tickets.

Problem 3: paid is not the same as captured

A webhook on order creation fires for orders whose payment later fails or is flagged for review. If your warehouse notification goes out on order creation, you will occasionally pick and ship goods for an order that never pays.

Trigger the fulfilment path on payment status rather than on order creation, and treat a pending or under-review payment as a hold rather than a go. The correct trigger is boring and it is the difference between a system you can leave alone and one somebody has to watch.

The same logic applies in reverse: a cancellation or refund after your scenario ran needs to reach the warehouse. If the only path is order creation, nobody downstream ever hears that an order was cancelled.

Problem 4: returns, where most automation stops

Returns are less predictable, so they get left manual entirely. That is an over-correction: roughly 70% of return requests follow a shape. The customer submits a request, the system checks that the order exists and is inside the window, approves, sends the label, updates the status.

The other 30% fall outside the rules and go to a person. Automating the 70% is a large saving and carries little risk, as long as the boundary is a rule and not the model's judgment. Anything touching a refund amount, a goodwill decision, or a customer who is already unhappy goes to a human by default.

The inventory loop, which is harder than orders

Order processing is a straight line. Inventory is a loop, and it is where most stores are still doing it by hand: checking stock and emailing suppliers when something looks low.

The automated version: a processed order decrements the SKU, and when a SKU crosses its reorder point a second flow drafts and sends the supplier order. We have run this for Simbago for over a year with no stockouts.

Two things make it work rather than misfire. Set the reorder point from sales velocity and supplier lead time rather than a flat number, because a SKU selling twenty a week needs a different trigger from one selling two. And for the first fortnight, send the draft to yourself rather than the supplier. An automation ordering the wrong quantity from a real supplier is an expensive way to discover your thresholds were guesses.

What you need

The stack is unremarkable and that is the point.

An automation platform: Make from $9/month covers most stores, n8n if you want self-hosting
A Shopify webhook on order events, configured in the admin under notifications - Shopify moves this occasionally, so search the admin rather than trusting a path from any article including this one
A channel the warehouse actually reads, which is usually not email
A sheet or database for inventory, if it is not already in Shopify
A courier API, if you want labels generated rather than typed
An email sending service for customer notifications

Cost, and when not to bother

Three to five days to build and test, $1,500-2,500 as a project, $9-16/month for the platform. It pays back within a month for a store doing 20+ orders a day.

Below about ten orders a day, do not. You will spend more on the build than the time is worth, and a person handling ten orders catches the odd ones automatically. Automate this when the volume has made that impossible, not in anticipation of volume you do not have yet.

Running a store and unsure which parts are worth automating first? The audit at 2pizza.team/audit takes two minutes, no call, and gives you an order of operations rather than a pitch.

Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.

10 December 2026: Your Privacy Policy Has to Name the Decisions Your Software Makes

2pizza.team — Wed, 30 Sep 2026 13:00:10 +0000

Not legal advice, an engineering read. From 10 December 2026, an APP entity that uses personal information in a computer program to make or substantially contribute to a decision that could reasonably be expected to significantly affect a person's rights or interests must say so in its privacy policy: what kinds of personal information, and what kinds of decisions. Civil penalties apply to a privacy policy that does not. The date is fixed in the legislation, not a target.

Most of the Australian AI regulation conversation this year has been about things that did not happen. The ten mandatory guardrails for high-risk AI were proposed, consulted on, and then shelved in favour of regulating through existing law. A lot of businesses built a mental compliance plan around those ten and are now aimed at nothing.

Meanwhile the obligation that did pass, quietly, inside the Privacy and Other Legislation Amendment Act 2024, commences on 10 December 2026. It is narrower than the guardrails and far more concrete, and it is the one with your name on it if you run automation that touches people.

Does it apply to you

Three conditions, and all three have to be true.

You are an APP entity: most businesses over the turnover threshold, plus health service providers and some others regardless of size
Personal information goes into a computer program that makes a decision, or does something substantially and directly related to making one
That decision could reasonably be expected to significantly affect someone's rights or interests

The second condition is wider than people assume and it is where most automation projects land. It does not require the software to make the final call. A scoring step that a human then rubber-stamps is substantially and directly related to the decision. The regulator has signalled a broad reading, so a system designed around the argument that a person technically decided is a system designed around a weak position.

What counts as significantly affecting rights or interests

Not defined exhaustively, and it will be argued at the edges. The clear cases are the familiar ones: credit and lending, employment and hiring, insurance, access to a service someone depends on, tenancy, anything about eligibility. The clearly-outside cases are equally familiar: a chatbot answering opening hours, a recommendation of which blog post to read next, routing an enquiry to the right inbox.

The uncomfortable middle is where most small businesses actually operate. Lead scoring that decides who gets called back is closer to the line than people expect, because the person who never gets called has had an outcome decided about them by software.

What the obligation is, precisely

This is a transparency measure and nothing more, and being precise about that saves a lot of unnecessary engineering.

What you must do:

Say in your privacy policy that personal information is used in automated decision-making
Say what kinds of personal information are used
Say what kinds of decisions are made that way

What it does NOT require:

A right for the individual to contest the decision
An explanation of the logic or the model
A right to human review
Direct notification of affected individuals

That second list matters as much as the first. Several vendors are already selling explainability and appeal workflows as though December requires them. It does not. Build those if your own standards call for them; do not buy them under the impression that the Privacy Act is asking.

The part that is actually hard

Writing the paragraph is an afternoon. Knowing what to write in it is the project, and this is where the deadline bites.

To describe the kinds of decisions your software makes, somebody has to enumerate them. In most businesses we look at, nobody can. Automation accretes: a scoring step here, a routing rule there, a threshold somebody set two years ago and left. The privacy policy is downstream of an inventory that does not exist yet.

The inventory that has to happen first:

Every automated step that consumes personal information, including the ones inside tools you did not build
For each, what it decides or contributes to deciding, in plain words
Which of those could reasonably be said to significantly affect someone
What personal information each one actually reads, not what the spec says it reads
Who owns it, because someone has to keep the policy true as the system changes

Third-party tools are the part that catches people. A CRM that scores leads, an email platform that decides send order by predicted engagement, a support tool that routes by sentiment: you did not build the model, but you chose to use it on your customers' personal information, and the decisions are yours.

What it means if you are building automation right now

Three engineering consequences, all of them cheap now and expensive in November.

Log what the system decided and on what inputs, per decision, from day one. Not for the regulator, who is not asking for it, but because the inventory above is impossible to reconstruct later from code.
Keep the decision points nameable. A pipeline where scoring, routing and thresholding are distinct, named steps can be described in a privacy policy. One where they are tangled through a prompt cannot.
Write the policy paragraph while you build, not after. If it is hard to write, the design is unclear, and that is worth knowing before launch rather than after.

A proportionate plan, if you are starting now

Eleven weeks is enough, and it is not a lot.

Weeks 1 to 2: inventory. List every automated step touching personal information. Expect the list to be longer than anyone predicts, mostly because of bought tools.
Weeks 3 to 4: triage. Mark the ones that plausibly affect rights or interests. When unsure, mark it in; the cost of disclosing something you did not have to is nothing, and the cost of the reverse is a penalty.
Weeks 5 to 6: write the policy text and have it reviewed by someone qualified. This is the step to spend money on.
Weeks 7 onward: fix the systems that could not be described, because that is the real finding.

One honest note on the last line. Every time we have run this exercise, the valuable output was not the policy paragraph. It was discovering two or three automated decisions nobody in the business knew were being made.

Verify current status and your own position with someone qualified before making a compliance decision. If you want the inventory done rather than the advice, that is a thing we build: the audit at /audit is free and takes two minutes. Ivan / 2pizza.team

Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.

8 Real n8n Automation Examples (With Use Cases and Outcomes)

2pizza.team — Tue, 29 Sep 2026 13:00:09 +0000

Most n8n examples online are trivial: connect Gmail to Slack, notify a channel when a row is added to a sheet. Useful for learning the tool, useless for understanding what it can do in a real business. Here are 8 automations we've actually built and deployed for clients.

1. Invoice reconciliation pipeline

What it does: ingests PDF invoices from email attachments, extracts structured data with Claude Vision, matches each invoice against open POs in a PostgreSQL database, auto-approves matches above 98% confidence, and sends a Telegram alert for exceptions with the discrepancy highlighted.

Details:

Trigger: email received with PDF attachment
Tools connected: Gmail, Claude API, PostgreSQL, Telegram
Outcome: 97%+ invoices processed without human involvement, monthly close time cut from 5 days to 1

2. Lead enrichment and qualification

What it does: when a form is submitted, the workflow fetches company data from Apollo, passes the enriched record to Claude to score ICP fit (1-5) with reasoning, routes high-scoring leads to a specific rep in the CRM with a Slack notification, and drops low-scoring leads into an automated nurture sequence.

Details:

Trigger: webhook from website form
Tools connected: Apollo, Claude API, HubSpot, Slack
Outcome: rep research time cut from 2+ hours/day to 20 minutes

3. Production reporting bot

What it does: field operators submit production numbers via Telegram throughout the day. n8n aggregates all inputs, calculates totals and variances against targets, Claude formats a plain-English daily summary, and leadership receives the report in Telegram each evening without anyone compiling it manually.

Details:

Trigger: scheduled (6pm daily) + Telegram message listener
Tools connected: Telegram Bot API, PostgreSQL, Claude API
Outcome: daily reporting shift from 45 minutes of manual aggregation to zero

4. WhatsApp customer support

What it does: incoming WhatsApp messages are classified by Claude into categories (order status, returns, product question, complaint, other). FAQ-type queries are answered directly from a knowledge base. Complaints and complex queries are routed to a human with a summary. All interactions are logged to the CRM with classification and resolution status.

Details:

Trigger: incoming WhatsApp message via Business API webhook
Tools connected: WhatsApp Business API, Claude API, HubSpot
Outcome: 75% of queries handled without human, response time under 2 minutes 24/7

5. Competitor monitoring

What it does: every Monday at 7am, n8n scrapes the pricing pages and feature pages of 5 competitor sites. Claude compares the current content to the version from last week and writes a brief highlighting what changed - new pricing, removed features, new product announcements. The brief lands in Slack before the team starts their week.

Details:

Trigger: weekly cron (Monday 7am)
Tools connected: HTTP scraper, PostgreSQL (stores previous versions), Claude API, Slack
Outcome: competitive changes caught immediately instead of weeks later

6. Contract expiry monitoring

What it does: a daily job queries a PostgreSQL contracts table for contracts expiring in the next 30, 60, and 90 days. For each one, Claude drafts a personalized renewal outreach email using the contract details. Drafts go into a review queue in Notion. The sales rep reads and approves or edits, then sends. No contract slips through unrenewed.

Details:

Trigger: scheduled daily
Tools connected: PostgreSQL, Claude API, Notion
Outcome: contract renewal rate increased, manual tracking spreadsheet eliminated

7. E-commerce abandoned cart recovery

What it does: when a Shopify checkout is abandoned, n8n waits 2 hours, then passes the cart details (products, prices, customer history) to Claude. Claude writes a personalized recovery email referencing what was left in the cart. The email is sent via Klaviyo from the brand's sending domain. Not a template - a generated email specific to that cart.

Details:

Trigger: Shopify webhook (checkout abandoned)
Tools connected: Shopify, Claude API, Klaviyo
Outcome: recovery rate 2x compared to previous template-based sequence

8. Supplier reorder automation

What it does: a daily job checks inventory levels for each SKU in a Google Sheet. When a SKU drops below the reorder threshold, Claude drafts a purchase order email to the supplier including SKU, quantity needed, and delivery address. The draft goes to a Telegram approval queue. One tap to send. All orders are logged to a tracking sheet.

Details:

Trigger: scheduled daily
Tools connected: Google Sheets, Claude API, Gmail, Telegram
Outcome: stockouts eliminated, reorder process cut from 1 hour to 5 minutes per week

Getting started with n8n

Verified September 2026 on n8n's own pricing page: cloud Starter is 20 EUR/month for 2,500 workflow executions, Pro is 50 EUR for 10,000, Business is 667 EUR for 40,000. Note the unit - n8n bills per workflow execution regardless of how many steps are inside it, which is why deep workflows are far cheaper here than on platforms that bill per module. Self-hosted community edition costs nothing to licence and runs on a VPS for $5-50/month with no execution limit, in exchange for owning uptime, updates and backups yourself.

What these cost to build

Rough bands for the eight above, so the list is useful rather than aspirational. A scheduled report or a reorder flow like numbers 3 and 8 is one to three days and $1,200-2,500. A qualification or support flow with a model doing judgment, numbers 2 and 4, is $2,500-6,000. The document pipeline in number 1 is $4,000-8,000, mostly because of the matching logic and the ERP integration rather than the extraction.

The part these examples hide

Each description above is the happy path, and the happy path is roughly a fifth of the work. What separates a demo from something you can leave running is the unglamorous half: what happens when a third-party API returns an error halfway through, whether a retried webhook can process the same record twice, whether a failure is loud or silent, and who finds out.

That is also where the price difference between quotes comes from. If two builders quote the same flow and one is half the price, the difference is almost always error handling, and you will meet it later.

Getting started

The learning curve is real: plan a day or two with the interface before building anything production. Start with a flow where a silent failure would be merely annoying rather than expensive, and add the error handling from the first build rather than after the first incident.

Want one of these automations built for your business? Book a free audit call and we'll scope exactly what it takes.

Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.

How to Automate a Shopify Store: Orders, Support and Reorders

2pizza.team — Mon, 28 Sep 2026 13:00:11 +0000

TL;DR: order processing $1,500-3,000, support AI $3,000-6,000, inventory reordering $1,000-2,500, roughly $5,000-10,000 for the full operations layer and $150-500/month to run. Start with order processing, it is the cheapest and it pays back fastest. Do not start with a chatbot.

Running a Shopify store means the same grind at every volume: every order confirmed, every question answered, every supplier chased when stock runs low. The work scales exactly with sales, which is why growing feels like drowning rather than winning.

Almost all of that manual time falls into three buckets. Here is what each one takes to automate, what it costs, and the mistakes that cost real money.

Where the time actually goes

From e-commerce clients: order processing and fulfilment coordination, customer support answering the same ten questions, and inventory management, meaning knowing when to reorder and chasing suppliers. All three are automatable, with very different effort and return.

Before automating anything, spend a week writing down where the time goes. Most owners are confident it is support and discover it is order admin. Building the wrong one first is the most expensive mistake available here, because it costs the money and leaves the bottleneck in place.

1. Order processing, start here

Shopify has a solid webhook API. An order arrives, a Make or n8n scenario fires: format the pick list, push it to whoever is packing, update the order status, send the customer a confirmation that actually says something. Four to eight hours to build, and then it runs. In the stores we have done this for, per-order handling drops from tens of minutes to a couple.

Worth automating in this bucket:

New order notifications to whoever picks, in whatever they actually read
Confirmation emails with real tracking, not a template that says thank you
Fulfilment status pushed back into Shopify so the storefront is not lying
A daily summary that tells you what shipped and what did not
Failed payment follow-up, which is usually the highest-return item on this list

The webhook trap that duplicates orders

Shopify does not guarantee a webhook is delivered exactly once. Retries happen, and a slow response on your side can produce a second delivery of an order you already processed. If your scenario is not idempotent, that becomes a duplicate pick, a duplicate confirmation email, and occasionally a duplicate charge somewhere downstream.

The fix is small and non-negotiable: record the order ID before doing anything else and ignore any delivery for an ID you have already handled. Ask anyone building this for you how they handle duplicate webhook delivery. If the question surprises them, that tells you what you need to know.

2. Customer support, and why not to start here

Between 60% and 80% of store support is answerable from a knowledge base: where is my order, what is the return policy, how long does shipping take, when is this back in stock. Build the knowledge base, connect it to a current model, deploy it in the channel your customers actually use. The system answers what it knows and escalates the rest. One client went from three to four hours a day on support to under thirty minutes.

It is second on the list rather than first for two reasons. It costs two to three times what order automation costs, and it is customer-facing, so a bad version does visible damage where a bad order script just annoys you.

The rules that keep a support bot from costing you customers

Three things, and the first is the one most implementations get wrong.

It must be able to say it does not know, and hand over cleanly. A bot that confidently invents a return policy creates a commitment you may have to honour.
Escalation must reach a human quickly and must carry the conversation with it. Making a frustrated customer repeat themselves undoes everything the automation saved.
Anything touching money, refunds, exceptions, or an angry customer goes to a person by default. These are the conversations that decide whether someone buys again.

The knowledge base is the actual product here, not the model. A support bot connected to accurate, current, well-structured answers works. The same bot on a stale help page produces confident nonsense. Budget real time for writing the content, and plan to revisit it when policies change.

3. Inventory and reordering

A scheduled job compares Shopify stock levels against reorder points you keep in a sheet. When a product drops below its threshold, the system drafts and sends the supplier email. Stockouts caused by nobody noticing stop happening, which is usually the single clearest return in the whole stack because a stockout costs you the sale and the customer.

Two refinements worth the extra hours. Set thresholds from actual sales velocity and supplier lead time rather than a flat number, because a product that sells twenty a week needs a different trigger than one that sells two. And have the first version send the draft to you rather than the supplier, for a couple of weeks, until you trust the thresholds. An automation that orders the wrong quantity from a real supplier is an expensive way to learn.

What to leave manual on purpose

Automation is not a completeness exercise. These stay with a human because the failure cost outweighs the time saved.

Refunds and goodwill decisions. Cheap for a person to judge, expensive for a system to get wrong.
Anything involving a complaint that has already escalated.
First contact with a new supplier, where the relationship is the point.
Product content and pricing changes, unless you genuinely want a bad price live at 3am.
The rare order type that happens twice a month. Escalate it; automating it costs more than it saves.

What it costs

Build and run, in the bands we quote:

Order processing: $1,500-3,000 to build, $50-100/month to run
Support AI: $3,000-6,000 to build, $100-300/month, most of it model usage that scales with ticket volume
Inventory and reordering: $1,000-2,500 to build, minimal running cost
All three as one operations layer: $5,000-10,000

Simbago is what the finished version looks like. Orders flow from the storefront and are processed automatically, supplier reorders fire on thresholds, and a chatbot handles the bulk of support. One warehouse worker runs an operation that would otherwise need three or four people, and does physical work only.

Deciding what to build first

Count the hours each bucket takes you in a normal week and multiply by what your time is worth. Then build the cheapest one that clears its cost inside a year, which for almost every store is order processing. Get that running, live with it for a month, and let the experience of it tell you whether support or inventory is next. Building all three at once is how projects stall at 80% and never quite land.

Want your specific store mapped and told what is worth automating first? The audit at 2pizza.team/audit is four questions and two minutes, no call needed.

Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.

You Are About to Hire a RevOps Manager. Read This First.

2pizza.team — Sun, 27 Sep 2026 13:00:10 +0000

TL;DR: about 85% of what a RevOps hire spends their week on is reporting, CRM hygiene and process docs, all of which are automatable today for $4,000-8,000 and $150-400/month, against $110,000 in year one for the hire. The other 15% is the part you cannot automate, and if that 15% is your real bottleneck, hire. Most founders posting this job have not worked out which it is.

I am Ivan, I run 2pizza.team. Every week I see the same posting on LinkedIn: Sales Operations or RevOps, $65-85k, must have three years of CRM experience, at a company somewhere between twenty and eighty people.

I know what is happening inside that company, because it is always the same thing. The founder is drowning in manual reporting. The CRM is a mess. Leads fall through because follow-up is manual. Sales data lives in five spreadsheets, three of which disagree. Hiring someone to own it feels obviously correct.

What actually happens after the hire

The search takes two to three months. The person joins, spends the first month learning the business, and produces a set of dashboards and a process document. Both are good. Six months later the founder is still pulling numbers by hand for the board deck, because the dashboards do not quite answer the question that gets asked.

Nothing went wrong. The hire is competent, the dashboards are fine. The problem is structural: you added one person to a volume problem that keeps growing, and one person does not scale with volume. The bottleneck moves about six feet and stays the same size.

Where the week actually goes

I asked several founders who had made this hire to break down where the time went. The shape was consistent enough to be worth repeating.

Around 40%: building and maintaining reports and dashboards
Around 25%: CRM cleanup, deduplication, data entry
Around 20%: writing process documentation and training people on it
Around 15%: the actual strategic work, meaning pipeline analysis and decisions

The first three categories are 85% of the role, and they are automatable now, with tools that exist, at a fraction of what the person costs. Not eventually. Not in principle. The fourth category is not automatable at all, and it is the reason the job exists in the founder's head.

That is the whole decision in one line: you are considering paying a full salary to get 15% of a role, and absorbing the other 85% as overhead because it came in the same package.

What automating the 85% actually looks like

Concretely, because this is where most articles wave their hands.

Reporting

A pipeline summary generated on a schedule from CRM data and delivered to Slack or email. Nobody pulls it. It is accurate because it runs against the source rather than against a copy of a copy, and it is identical every week, which makes it comparable week to week - something hand-built reports almost never are.

CRM hygiene

New records enriched on arrival with company size, industry and contact data. Duplicate detection at import rather than at quarterly cleanup. Deal stages moved by observed activity rather than by someone remembering to update them. This is the category that quietly decides whether any of your reporting means anything.

Follow-up

A deal goes quiet for seven days and a task appears. A form gets submitted and a relevant reply goes out in minutes rather than at the end of the day, generated against criteria you set and reviewed by rules you wrote. The gain here is not the writing; it is that nothing is dropped when someone is on holiday.

Process documentation

The partially automatable one, and worth being honest about. A system can keep a record of how the process actually runs, which is more accurate than a document describing how it was supposed to. It cannot persuade a sales team to follow it. That part is human and it stays human.

The arithmetic, both sides

The general version of this trade, across any role rather than RevOps specifically, is in automation versus hiring. A $70,000 RevOps salary lands at roughly $90,000-95,000 all-in once taxes and benefits are counted. Add $15,000-20,000 in year one for recruitment and the ramp period you pay for and do not get output from. Call it $110,000 before the person is fully productive, recurring annually and rising.

Building the automations above runs $4,000-8,000 depending on your CRM and how clean the data is, with $150-400/month to operate. Payback under two months on the time saved alone. In year two the comparison is not close, because one line recurs in full and the other drops to the running cost.

The system also does not resign eighteen months in, taking the undocumented half of how everything works with it. That is not a joke about headcount; it is the single most expensive thing that happens to small-company operations, and it happens on a schedule.

When you should hire anyway

Four cases, and they are real. I have told people to hire in all four.

The bottleneck is stakeholder management. Getting sales, marketing and finance to agree on what a qualified lead is has never been a tooling problem.
Your process genuinely changes every quarter. Automation encodes a process; encoding one that is about to change is paying twice.
Nobody can state how the work is done today. Then the first job is extraction from someone's head, and a person does that better than a spec.
You need someone accountable in the room. A system has no opinion in a pipeline review and cannot be asked why the forecast slipped.

If one of those is your situation, hire, and hire well. Just do not also expect the hire to fix reporting, because they will spend 40% of their week on it forever.

The failure mode on my side of the argument

Automating instead of hiring goes wrong in one specific way, and I would rather you hear it from me. You automate the reporting and the CRM hygiene, the founder's Monday gets shorter, and nobody ever does the 15% strategic work, because it was never anyone's job and now the pain that would have forced the hire is gone.

Six months later the numbers arrive beautifully every Monday and nobody is analysing them. That is a worse outcome than the messy version, because it feels solved. If you go the automation route, put the pipeline analysis on someone's actual calendar, by name, or you have bought silence rather than insight.

The order I would do it in

Automate the 85% first, live with it for a quarter, then look at what is left. What remains is the real job description, and it is a much better one: someone who does pipeline analysis and cross-functional work on top of a system that already runs, rather than someone who spends their first year rebuilding reports by hand.

You will also hire better, because the role you are advertising is now interesting. The best operations people do not want to own a spreadsheet ritual, and the posting you were about to publish is, read plainly, a spreadsheet ritual with a salary attached.

Have a RevOps posting open right now? The audit at 2pizza.team/audit takes two minutes and no call, and it will tell you which side of the 85/15 split your actual bottleneck sits on. If it is the 15, it will say hire.

Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.

n8n vs Make: How to Choose, With Verified 2026 Pricing

2pizza.team — Sat, 26 Sep 2026 13:00:10 +0000

TL;DR: Make bills per module execution, n8n bills per workflow execution regardless of how many steps are in it. That single difference decides most cost comparisons: deep workflows favour n8n, shallow high-frequency ones favour Make. Choose Make if a non-developer maintains it. Choose n8n if you have a developer, need self-hosting, or run deep workflows at volume.

Once you have ruled out Zapier on price or power, these are the two serious options. Both are far more capable than Zapier, both cost less to run, and they are not interchangeable. Picking the wrong one is recoverable but not free, so it is worth twenty minutes now.

The difference that decides everything else

They do not bill the same unit, and almost every comparison you will read glosses over this.

Make charges a credit per module execution. A scenario with twelve modules that runs once costs roughly twelve credits. n8n charges one workflow execution per run, no matter how many nodes are inside it. A twelve-node workflow running once costs one execution.

So the cost question is not really 'how much volume do you have'. It is 'how deep are your workflows'. A shallow three-step flow running constantly is comparatively cheap on Make. A twenty-step document pipeline running a few thousand times a month is dramatically cheaper on n8n, because you pay once per run rather than twenty times.

Do this maths before you choose

Count the billable steps in your typical workflow and the runs per month. On Make, multiply the two. On n8n, take the runs alone. Then price each against the tables below. If your workflows are short, the numbers will land close together and the decision comes down to team and compliance. If your workflows are long, the numbers will not be close.

Verified prices, September 2026

Taken from each vendor's own pricing page rather than repeated from other articles, several of which are quoting tiers that no longer exist.

Make, per credit (a module execution; the trigger is free):

Free: $0, 1,000 credits/month, 15-minute minimum interval between runs
Core: $9/month for 10,000 credits, unlimited active scenarios, Make API
Pro: $16/month for 10,000 credits, priority execution, full-text log search
Teams: $29/month for 10,000 credits, team roles and shared templates
All paid tiers scale on a slider from 10,000 credits up past 8 million a month

n8n cloud, per workflow execution regardless of step count (billed annually):

Starter: 20 EUR/month, 2,500 executions, 5 concurrent, 2,300 AI credits
Pro: 50 EUR/month, 10,000 executions, 20 concurrent, workflow history and execution search
Business: 667 EUR/month, 40,000 executions, plus a self-hosted option, SSO and Git version control
Enterprise: custom, with log streaming and extended retention

Self-hosted n8n is the other branch entirely. The community edition costs nothing to license; you pay for a server, realistically $5-50/month on a VPS depending on load, and there is no execution limit at all. That is where the large cost gaps appear, and it is also where you take on uptime, updates and backups as your own problem.

Note the version-control line on the Business tier. If you want your automations in Git, reviewed like code, that is a paid n8n tier or self-hosting. It is a genuine differentiator and it rarely shows up in comparisons.

Where Make wins

Make's advantage is not technical, it is organisational, and that makes it more valuable than it sounds.

A non-developer can open a scenario built six months ago and understand it. This matters more than any feature on either list.
Setup is fast, and the module library covers 1,000+ apps with authentication that mostly just works
Error handling, retries and error routes are solid out of the box rather than configured
Nothing to host, patch or monitor
Predictable small bills at moderate volume, typically $9-29/month

And where it stops

It is cloud only, so your data passes through their infrastructure, which ends the conversation for some compliance requirements. Custom code is possible but awkward. Deep workflows get expensive because every module bills. And some logic that is three lines in code becomes an uncomfortable arrangement of modules on a canvas.

Where n8n wins

n8n's advantages are the ones that matter when the system becomes infrastructure rather than convenience.

Self-hosting, so data never leaves your infrastructure. This is the decisive factor for GDPR-sensitive, healthcare and finance work.
No per-step billing, which is what makes deep pipelines affordable
A code node that lets you write JavaScript inline, so anything you could script, you can do
Complex branching and sub-workflows that compose more naturally
Version control and real environments on the paid or self-hosted routes
No vendor lock-in in the meaningful sense: you can take the whole thing with you

And where it costs you

A steeper curve, and a real one: the interface is powerful and less forgiving. Self-hosting means you own uptime, updates and backups, and a production workflow needs monitoring you have set up yourself. The native integration library is smaller than Make's, though the HTTP node covers anything with an API at the price of more configuration. And n8n cloud, which removes the ops burden, also removes the cost advantage that made self-hosting attractive.

Integrations, honestly

Make has 1,000+ native connectors, n8n has several hundred plus generic HTTP. In practice both connect to anything with an API and the real difference is how much manual configuration a less common tool takes. For Shopify, HubSpot, Salesforce, Airtable, Notion, Slack and Google Workspace, both are fine and this should not drive your decision.

What we actually use

Roughly 70% of our client builds run on Make. It handles standard requirements efficiently and, crucially, the client can understand what we built and change it without us. We reach for n8n on compliance-bound work, on high-volume document processing where Make credits would scale badly, and on anything needing real code inside the workflow.

A fair number of systems use both. Make orchestrates the shallow, frequently-modified, business-facing flows; n8n does the deep processing behind a webhook. The handoff is clean and each tool does what it is good at. If that sounds like over-engineering, it is, right up until the month a single pipeline's credit usage exceeds the server bill several times over.

A decision procedure, in order

Answer these in sequence and stop at the first one that applies.

Does data residency or self-hosting compliance apply? Then n8n. Nothing else in this article outranks that.
Will a non-developer own and modify this? Then Make, even if n8n is cheaper on paper. An automation nobody can safely edit becomes a liability.
Are your workflows deep, more than about ten billable steps, and running at real volume? Then run the maths above; n8n usually wins by a lot.
Do you need the logic in Git, reviewed like code? Then n8n, on a paid tier or self-hosted.
None of the above? Make. Start there, and know that migrating to n8n later is a normal, survivable project.

If you are choosing between these two and Zapier is still in the conversation, our three-way comparison covers that ground with the same numbers.

Want the maths run on your actual workflows before you commit to either? That is a short job and we will do it. Start with the audit at 2pizza.team/audit, two minutes, no call.

Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.

The Privacy Act and AI Automation: What an Australian Business Actually Has To Do

2pizza.team — Fri, 25 Sep 2026 13:00:11 +0000

Not legal advice. This is how we design systems for Australian clients, written by engineers. Anything with real regulatory weight should go past your own adviser before it goes live. What follows is the practical shape of the obligations, not a compliance opinion.

Most Australian businesses meet the Privacy Act for the first time as a document exercise: someone writes a privacy policy, it goes on the website, everyone moves on. Then an automation project touches customer records and the questions get real, usually in the middle of a build when they are most expensive to answer.

Does it even apply to you

The Privacy Act 1988 applies to Australian Government agencies and to private sector organisations above an annual turnover threshold, with a set of carve-ins that catch smaller businesses anyway. Health service providers are the big one - they are covered regardless of turnover, because health information is treated as sensitive information with a higher bar. Businesses trading in personal information, and contractors delivering Australian Government contracts, are also caught.

If you are a small business that has assumed it is exempt, check the carve-ins rather than the turnover number. We have had this conversation with clients who were confidently outside the threshold and firmly inside a carve-in. Note too that the reform direction has been to narrow the small business exemption over time, so building as though it applies is the safer engineering choice even where it currently does not.

The principles that actually bite on an automation project

There are thirteen Australian Privacy Principles. On a typical automation build, five of them do most of the work and the rest follow if you get those right.

Collection and notification - you collect only what you reasonably need for the function, and people know you are collecting it. In practice this kills the habit of syncing an entire table between systems because it was easier than selecting columns.
Use and disclosure - information collected for one purpose does not quietly become training data, a marketing list, or an input to a different system, without consent or another lawful basis.
Cross-border disclosure - sending personal information overseas makes you accountable for what happens to it. This is the one that catches AI projects, because the model provider is usually offshore.
Security - reasonable steps to protect information, and to destroy or de-identify it when it is no longer needed. Retention is an obligation, not a storage preference.
Access and correction - a person can ask what you hold and have it corrected. If your data is scattered across six systems with no map, answering that request is a project rather than a task.

The cross-border question, which is the one about AI

The moment your automation sends customer text to a model API, you are disclosing personal information to an overseas recipient, and you carry accountability for it. That does not make it prohibited. It makes it something you have to do deliberately.

Strip what you do not need before the call. Most prompts do not require a full name, an address, or an account number to do their job. Redaction before the API boundary is the single highest-value control in an AI build.
Check the provider's data handling and retention terms, and whether inputs are used for training. Enterprise tiers from the major providers contractually exclude training on your inputs. Consumer tiers historically have not.
Prefer a region that reduces the exposure where the provider offers one. Several offer Australian or at least regional processing.
Say so in the privacy policy. Vague wording about 'third party service providers' is doing a lot of work that a regulator may not accept.
Consider whether the task needs a general model at all. A gradient boosting model trained on your own tabular data, running on your own infrastructure, discloses nothing to anyone.

Automated decisions are the part people miss

The reform direction in Australian privacy law has been towards transparency about automated decision-making that significantly affects individuals. The practical consequence for an engineering team is that if a system decides something material about a person - credit, eligibility, pricing, prioritisation, who gets contacted - you need to be able to say that it does, and broadly how.

This is a strong argument for the model choice we already push for other reasons. A gradient boosting model returns the features that drove each decision, so explaining it is a reporting exercise. A language model asked to produce a score returns a number with no traceable derivation, and explaining that to a regulator or an affected customer is not a reporting exercise, it is an admission.

If you are building anything that makes consequential automated decisions about people, verify the current commencement dates and the exact wording with your adviser rather than with a blog post. The direction of travel is settled; the detail and the timing are the part that changes.

Notifiable data breaches, and why it changes the build

Australia has a mandatory notifiable data breach scheme. An eligible breach - one likely to result in serious harm - has to be assessed and notified to the regulator and to affected individuals. The engineering consequence is that you need to be able to answer, quickly and with evidence, what was exposed and whose information it was.

That answer comes from logging you built earlier or it does not come at all. A system with no audit trail turns a contained incident into an unbounded one, because you cannot demonstrate the bound. This is why we log data access rather than only data changes, and why we resist the shortcut of a service account that reads everything.

What this looks like as engineering decisions

None of the above is a document. It is a set of choices that are cheap at the start of a build and expensive to retrofit.

Select columns rather than syncing tables. Every field you move is a field you are accountable for.
Redact before the API boundary, not after. Once it has left, it has left.
Role-based access, with no shared service account that can read everything.
Audit log reads as well as writes, with enough detail to answer a breach assessment.
Set retention at build time, with an actual deletion job. Data kept forever because nobody decided is the default failure.
Document the data flow as a diagram. If nobody can draw where personal information goes, nobody can answer an access request either.

One industry-specific warning

If you are in regulated health services, advertising rules under the National Law sit on top of privacy obligations and are considerably stricter than most industries face - testimonials in advertising regulated health services are prohibited outright. We learned that shape of constraint building for an Australian medical client, where every piece of generated content had to pass a compliance gate before publication. If AI is generating any customer-facing copy in a regulated field, the gate has to be a hard block in the pipeline, not a review step someone can skip when they are busy.

We build with these constraints designed in for Australian clients as a default, because retrofitting them is where projects blow their budget. If you want a second opinion on a build you already have, the audit at /audit is free and we will tell you what we would change. Ivan / 2pizza.team

Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.

How to Automate Customer Support Without Wrecking It

2pizza.team — Thu, 24 Sep 2026 13:00:12 +0000

TL;DR: a well-built support system handles 70-80% of tickets without a human. The 70-80% is not a model capability, it is a property of your ticket mix, so measure it before you build. The knowledge base is the product; the model is a component. And ship it drafting replies for a human before you let it answer anyone directly.

Support automation fails in a specific and predictable way. Someone connects a model to a help page, it answers confidently and wrongly, customers get angry, and the project is written off as a technology problem. It was not. It was an architecture problem, and the architecture is not complicated.

Step 1: count your actual tickets before you build anything

Pull the last few hundred tickets and sort them into three piles. Answerable from documented facts. Answerable but needs account data. Needs a human judgment call.

The first pile is your automation ceiling, and it is knowable in an afternoon. In most businesses it is 50-70%, and adding the second pile once you have integrated order and account lookups takes it to 70-85%. If your first pile is 20%, no tool will get you to 80% and anyone promising otherwise has not looked at your tickets.

This exercise has a second payoff that often exceeds the first. The most common question in the pile is usually something you could fix at the source. If four hundred people a month ask where their order is, the answer is better shipping notifications, not a faster way to answer the question.

Step 2: build a knowledge base, not a bot

The single biggest determinant of quality is the content the system answers from. A capable model over accurate, current, well-structured content is reliable. The same model over a stale help page produces confident nonsense, because that is what it was asked to do.

What goes in:

Policies as they are actually applied, including the exceptions your team makes in practice
Product facts: specifications, compatibility, what is and is not included
Process answers: shipping times by region, returns, warranty, how to change an order
The genuine answers to your top twenty questions, written the way your team would say them
Explicit statements of what the system must not answer, which matters as much as what it should

Write it as answers, not as marketing pages. And put a review date on it. The failure mode nine months in is not the model getting worse, it is a policy changing and nobody updating the source.

Step 3: retrieval, so answers come from your data

The model should not be answering from what it absorbed in training. It should be handed the relevant passages from your knowledge base and asked to answer from those, citing which it used. That is retrieval-augmented generation, and the reason it matters is not accuracy in the abstract, it is that you can trace any answer back to the source that produced it.

Two practical rules. If retrieval returns nothing relevant, the correct behaviour is to escalate, not to try. And answers should be traceable, so that when one is wrong you fix the source document rather than argue with a prompt. A system you cannot debug is one you will stop trusting.

Step 4: define escalation explicitly

Escalation must be rules you wrote down, not a judgment the model makes about its own confidence. Confidence is exactly the thing these systems are worst at reporting.

Escalate immediately, without attempting an answer:

Anything about refunds, chargebacks or money owed
Any message with an angry or distressed tone
Anything mentioning legal action, a regulator, or a public complaint
Anything where retrieval found nothing relevant
A repeat contact about an issue already raised: second touch goes to a person
Anything about safety, health, or a defective product
Any request the system has already failed once

The handover has to carry the whole conversation with it. Making an already-frustrated customer repeat themselves to a human undoes every minute the automation saved, and it is the detail most implementations get wrong.

Step 5: ship it as a draft writer first

This is the pattern that separates projects that land from projects that get switched off in week three. For the first few weeks the system does not talk to customers. It drafts a reply, an agent reads it, edits if needed, and sends.

Why this is worth the delay:

You find out what it gets wrong on real tickets while the cost of being wrong is zero
Your team gets faster immediately, so the project delivers value from week one
Every edit an agent makes is a defect report pointing at a knowledge base gap
The team ends up trusting it, because they watched it earn it rather than being told to

When the edit rate on a category drops to near zero, let that category answer directly. Promote category by category, never all at once. Categories with money or emotion in them may never graduate, and that is a correct outcome rather than a failure.

Step 6: channels and stack

Put it where your customers already are rather than where it is easiest to deploy. Email is the simplest to automate well and usually the highest volume. Live chat has the highest expectations and the least tolerance for a wrong answer. A help-centre search that actually answers is underrated and low risk. Social DMs are the hardest to do well because the tone is public.

The stack is unremarkable and should be: your helpdesk as the system of record, a retrieval layer over your knowledge base, a current model doing the writing, and Make or n8n as the connective tissue. None of these choices are where the project succeeds or fails.

Step 7: measure four things, not activity

Tickets deflected is a vanity number on its own. These four together tell you the truth.

Resolution rate without human touch, by category. One number for the whole queue hides everything useful.
Escalation rate, and whether escalations are arriving early or after a failed attempt. Late escalations are the expensive kind.
Reopen rate on automated answers. This is the honesty check: a high deflection rate with a high reopen rate means you moved work, not removed it.
Satisfaction on automated versus human replies, tracked separately. If the gap widens, stop promoting categories.

Maintenance, which is not optional

Budget a couple of hours a month and a named owner. The recurring work is small and specific: review escalations for patterns that should have been handled, review the answers agents edited, update the knowledge base when policy changes, and retire content for products you no longer sell.

The systems that decay are the ones with no owner. Nothing breaks loudly; the content just drifts out of date and the answers get quietly worse until someone notices in a review three months later.

What good looks like

Seventy to eighty percent of tickets resolved without a human, response times measured in seconds for that share, agents spending their day on the cases that actually need judgment, and a reopen rate no worse than it was before. Cost is typically $3,000-6,000 to build and $100-300/month to run, most of the running cost being model usage that scales with volume.

One client went from three to four hours a day on support to under thirty minutes. The team did not shrink. The person who had been answering the same ten questions started doing the work that had been waiting all year.

Not sure what share of your tickets is genuinely automatable? That is a counting exercise, not a sales call. The audit at 2pizza.team/audit takes two minutes and will tell you where to start.

Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.

Custom ERP vs Off-the-Shelf: How to Decide

2pizza.team — Wed, 23 Sep 2026 13:00:09 +0000

TL;DR: focused custom tool $8,000-25,000, multi-workflow system $20,000-60,000, eight to sixteen weeks. But most businesses that think they need custom actually need the middle path: keep the tools, build only the layer between them. Read that section before the cost one.

The default advice is always to use off-the-shelf. It is cheaper, faster, and somebody else maintains it. That advice is right most of the time, and I give it regularly to people who came to us wanting something built.

There is a class of business where it stops being right, and the tell is not that a tool failed. It is that the workarounds have become their own system, and nobody can describe how the business runs without describing the workarounds.

What generic tools are genuinely good at

They shine when your workflow matches their assumptions: standard order management, ordinary project tracking, common financial processes, typical HR flows. If you sell standard products, ship them, and track normal inventory, an off-the-shelf stack handles it and will keep handling it. The tools were built for you, and no bespoke system will beat them on price or on the fact that someone else is patching them at 3am.

The signals you have actually outgrown them

Not a single failure. A pattern, and you will recognise more than one of these.

Three or more spreadsheets are the real source of truth for core operations, whatever the tools say
Someone exports from one system and imports into another every week, by hand
A tool is customised so heavily that its own updates break your configuration
New hires take three months to learn how the work is actually done, as distinct from how the software expects it to be done
You pay for six or more SaaS tools and the gaps between them are still manual
The person who understands the workarounds is a single point of failure and everyone knows it

That last one is the one that usually decides it, and it is rarely what people come in talking about. A process that lives in one person's head is a business risk regardless of software.

The middle path, which is what most people actually need

Between living with the mess and building an ERP there is an option that gets skipped, and it is cheaper than both.

Keep the tools that work. Build only the layer between them: the integration that moves data so nobody exports anything, plus one interface over the top for the few screens your team actually needs. Your accounting stays where it is. Your storefront stays where it is. What you build is the part that does not exist in any product, because it is specific to you.

Why this is usually the better trade:

A fraction of the cost: typically $3,000-10,000 against $20,000+ for a system
Weeks rather than months, so the pain stops sooner
You keep the vendors' maintenance, security patching and compliance work
It is reversible. A failed integration layer costs you the layer, not your operations.

We propose this more often than we propose a build, and it is a smaller invoice for us. The reason is simple: it is right more often, and a business that regrets a $40,000 system does not come back.

What custom actually means at this size

Not a multi-year enterprise implementation. For a business somewhere between half a million and ten million in revenue it means a web application built around your operations, your vocabulary and your edge cases, talking to what you already use over APIs, running in a browser. It should look like a simple internal tool, because that is what makes people use it.

Three we have built. For a construction company, a project tracker combining procurement requests, subcontractor timesheets, milestones and invoices, replacing four tools and a dozen spreadsheets. For a logistics operator, an invoice portal tracking shipments, generating invoices on contracted rates and pushing to accounting. For a confectionery studio, B2B ordering joined to production planning, so wholesale orders arrive online and the production team sees what to make that morning.

The costs nobody puts in the proposal

The build price is the part everybody quotes. These are the parts that decide whether you regret it.

Maintenance forever. Dependencies age, integrations change, browsers move. Budget something every year, not nothing.
The bus factor moves to you. With SaaS, the vendor employs the people who understand it. With custom, that knowledge is a document and a repository, and it decays.
Change requests are now a project. Adding a field in a SaaS tool is a click. In your system it is a ticket, a build and a deploy.
Compliance and security are yours. Whatever rules apply to your data, you now own the work of meeting them.
Hosting and infrastructure, small but permanent.

The honest comparison is not build price against SaaS subscriptions. It is build plus five years of the above against subscriptions plus the cost of the manual work you are doing today. Run it over five years and some projects that look obvious stop looking obvious.

What you must own when it is finished

Non-negotiable, and worth writing into the agreement before anyone starts.

The source code, in your repository, under your account
The infrastructure accounts, billed to you, not sitting inside an agency workspace
Your data, exportable in a format you can read without the application
Documentation good enough for a competent third party to take over
A written answer to what happens if the agency disappears

A builder who resists any of this is selling you a dependency rather than a system. The point of custom software is control; if you do not get control, you have bought the expensive option and kept the lock-in.

Cost and timeline

These sit at the top of the bands in our pricing article. One core workflow, built properly: $8,000-25,000. Three or four workflows: $20,000-60,000. Against six SaaS tools at $100-400 a month, which is $7,200-28,800 a year before counting the hours spent moving data between them.

Eight to sixteen weeks end to end: a fortnight documenting the process and designing, most of the middle building with regular check-ins, a few weeks testing and iterating, then deployment and training. Adoption tends to be fast for one reason: the people using it on day one are the people who specified it.

When not to build

Clearly and without hedging.

Your process is still changing. Encoding a process that will be different next quarter means paying twice.
Nobody can describe how the work is done today. Extract that first; it is a different and cheaper project.
The real problem is that two departments disagree about the process. Software will not settle that argument, it will just make it expensive.
You have not honestly tried the middle path.
Revenue is small enough that the money matters more than the hours. Below roughly half a million, live with the mess a while longer.

The test that settles it

Write out one core process step by step. Against each step, name the tool that handles it. Then count two things: gaps, where no tool fits and a person does it by hand, and handoffs, where data crosses from one tool to another.

More than five gaps or four handoffs in a single core process and the arithmetic for building usually works. Fewer, and you are looking at an integration problem wearing an ERP costume, which is the middle path and a tenth of the price.

Hitting the limits of your current tools? The audit at 2pizza.team/audit takes two minutes and no call. If the answer is that you need an integration rather than a system, it will say that.

Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.

Zapier vs Make in 2026: The Honest Comparison

2pizza.team — Tue, 22 Sep 2026 13:00:11 +0000

TL;DR: Zapier is faster to start and more expensive to run. Make is cheaper at any real volume and better at complex logic. Start on Make unless you have a specific reason not to. Pricing below was checked against both vendors' own pages in September 2026, because most comparisons you will find are quoting tiers that no longer exist.

Most comparisons of these two are written by affiliates who earn on whichever link you click. We build production automation on both and charge the same either way, so we have no reason to steer you. What we do have is the experience of migrating a lot of businesses off one and onto the other, which is a different and more useful kind of bias.

What changed in 2026, and why old articles are wrong

Both vendors restructured, and the majority of comparison articles still online have not caught up. Two changes matter.

Make renamed operations to credits

The unit is the same idea, a module execution, but every guide that talks about 'operations' is now using a word Make does not. If you are reading a tutorial that says operations, it still applies, the vocabulary just moved.

Zapier removed the Starter tier

The old ladder of Free, Starter around $20, Professional around $50 is gone. Today it is Free, Professional from $19.99/month, Team from $69/month, Enterprise on request. Zapier also moved AI steps, code steps and the SDK onto the same task-based pricing as everything else. If a comparison quotes Zapier Starter, it was written before this and its cost conclusions are stale.

The actual prices, September 2026

Checked on make.com/pricing and zapier.com/pricing directly rather than repeated from elsewhere.

Make:

Free: $0, 1,000 credits/month, 15-minute minimum interval between runs, limited active scenarios
Core: $9/month for 10,000 credits, unlimited active scenarios, scheduling down to the minute, Make API access
Pro: $16/month for 10,000 credits, priority execution, custom variables, full-text execution log search
Teams: $29/month for 10,000 credits, team roles and shared templates
Enterprise: custom, and the credit slider runs up past 8 million a month

Zapier:

Free: $0, 100 tasks/month, two-step Zaps only
Professional: from $19.99/month, multi-step Zaps, premium apps, webhooks
Team: from $69/month, 25 users, shared connections, SSO
Enterprise: custom

Both headline prices are for the smallest usage bucket and both scale on a slider, so the starting number is the least interesting part. The comparison that matters is what a real workload costs, and for that you need to understand that the two count differently.

Tasks and credits are not the same unit

This is where most cost comparisons go wrong. Zapier bills a task per action step that successfully runs. Make bills a credit per module execution, including routers, filters with an outcome, aggregators and error handlers, but not the trigger. A ten-module Make scenario running 500 times is roughly 4,500-5,000 credits, not 500. Comparing headline plan prices without normalising for this tells you nothing.

Normalise before you compare. Count the billable steps in your workflow, multiply by monthly runs, add 20% for error paths, then price that number on each platform's slider. Do that once and the decision usually makes itself.

When Zapier is genuinely the right call

It is a real product with real advantages and the honest list is short but not empty.

You need one simple automation working today and you are not technical. Zapier's setup is roughly 15 minutes against Make's 45. For a founder whose hour is worth more than the annual price difference, that is rational.
Your specific tool has a Zapier connector and nothing else. Integration breadth on obscure apps is still Zapier's strongest card, and no amount of cost advantage helps if the connector does not exist.
Your volume is genuinely tiny and will stay that way. Below a few hundred runs a month the cost difference is noise.
Someone non-technical on your team will own it. Zapier's interface forgives more.

When Make wins, which is most of the time

Everything that scales points the same direction.

Cost at volume

This is not close. Once you are past a few thousand runs a month, Make is multiples cheaper for equivalent work. The exact ratio depends on how you normalise tasks against credits, but in the migrations we have done the bill typically lands somewhere between a third and a tenth of what it was.

Complex logic

Multi-branch workflows are dramatically easier to build and, more importantly, to read six months later in Make's visual canvas. Zapier's linear model fights you as soon as the process has real branching. If your workflow has more than three or four decisions in it, this alone justifies the choice.

Error handling and data work

Make gives you proper error routes, retries, loops and data transformation as first-class features. In Zapier a lot of that becomes a code step, which works but means you now maintain code inside a no-code tool, which is the worst of both.

The exit

If you eventually outgrow Make, usually for self-hosting, data residency or cost at serious volume, moving to n8n is meaningfully easier from Make than from Zapier because the workflow logic maps more directly. Choosing Make keeps a door open.

What a migration actually costs

Most clients who arrive on Zapier move to Make during the first project. Worth being straight about the effort involved, because the savings get quoted and the work does not.

Zaps do not import. Every workflow is rebuilt, which means re-authenticating each connected app, re-mapping fields, and re-testing against real data. Budget roughly half a day per non-trivial Zap, more if the original had accumulated undocumented fixes, which they generally have. The upside is that the rebuild forces you to look at workflows nobody has reviewed in two years, and in most migrations we delete a few outright because the process behind them no longer exists.

A migration is clearly worth it when:

Your Zapier bill has moved into the hundreds per month
You are working around Zapier's structure with code steps or chained Zaps
You are about to build something substantially more complex than what you have
You need error handling that does more than email you after the fact

It is not worth it when:

You have a handful of simple Zaps and a bill under $30/month
The person who maintains them is non-technical and happy
You are about to change the underlying process anyway

The case where the answer is neither

Both are the wrong tool when the work is not really integration. If you are processing high volumes of real-time events, running custom models, or need the logic to live in a repository under version control with tests, you want n8n self-hosted or plain code. Paying per credit for something that should be a service is a slow, quiet way to overspend.

The signal to watch for: you find yourself building around the platform rather than with it. Chained scenarios to dodge a limit, code modules doing the real work, a webhook fan-out that exists because the tool cannot loop the way you need. That is the platform telling you it is finished.

What we recommend

Start on Make unless one of the Zapier cases above describes you exactly. The learning curve is a weekend rather than a month, the cost advantage is material at any volume worth automating, and the migration path onward is better. If you are already on Zapier and it is working at a low bill, leave it alone until one of the migration triggers fires. Switching tools for elegance is a cost with no return.

On Zapier and wondering whether to move? We do Zapier to Make migrations as fixed-price projects, and we will tell you when the answer is to stay put. The audit at 2pizza.team/audit takes two minutes and needs no call.

Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.

Generative Engine Optimization: What the Data Actually Supports in 2026

2pizza.team — Mon, 21 Sep 2026 13:00:09 +0000

TL;DR: The order that matters is access, entity, shelves, placements. Placements are the main lever and the slowest. llms.txt is placebo. General schema markup does not move citations. Nobody can guarantee you a hit rate, and the lag from publication to appearing in answers runs four to eight weeks. Everything below is sourced.

Generative Engine Optimization is eighteen months old as a category and almost entirely unpoliced. That combination produces a lot of confident decks. This post is the version of the playbook we actually run, with the evidence attached and the weak parts labelled as weak.

What GEO is, in one paragraph

Classic search optimization tries to rank a page. Generative engine optimization tries to get your brand named and cited inside an answer that an engine composes on the fly. The buyer never sees ten blue links - they see three names and a paragraph of reasoning. If you are not in the three, the ranking of your page is irrelevant to that particular buyer.

Where brands actually drop out

An engine assembles an answer in stages: retrieve candidate sources, resolve the entities involved, decide which names belong in the set. You can fall out at any of the three, and the fixes are completely different at each stage. Diagnosing the wrong stage is the most common way a GEO budget gets wasted.

Retrieval - the crawler never got your content. Blocked at the firewall, or served an empty shell because your app renders in the browser.
Entity - it retrieved you but is unsure who you are. Inconsistent naming, two brands under one legal entity, prices that disagree between pages.
Set membership - it retrieved you, it understands you, and it still left you out, because the sources it trusts for your category never mention you.

Layer one: access, and the Cloudflare problem

Since July 2025 Cloudflare has blocked AI crawlers by default on new zones. This is the single most common blocker we find, and most teams have no idea it is switched on. If OAI-SearchBot cannot fetch your pages, you are absent from ChatGPT Search regardless of the quality of anything else you have built. It costs nothing to check and usually one afternoon to fix, which makes it the highest return per hour in the entire discipline.

The second access failure is client-side rendering. Crawlers do not execute your JavaScript. A single-page app can serve a two-kilobyte shell to every engine while looking perfect in a browser. Check what the bot receives, not what you see. If the answer is an empty shell, prerendering is your first project and nothing else in this list matters until it ships.

Layer two: entity hygiene, which is hygiene and not growth

One Organization object with a stable identifier. Consistent name, founding date and address everywhere. sameAs pointing only at profiles that exist. No contradictory facts across pages - pricing is the usual offender, where an old landing page still shows a number the current pricing page abandoned. This work changes how an engine answers a question like 'is this company legitimate'. It does not get you into 'best X'.

A specific trap worth naming: if two brands sit under one legal entity, engines often merge them into a single confused entity. We found exactly this on our own properties - one company name appearing as the parent of two unrelated products, which produced hedged answers about both. Splitting the attribution is unglamorous work with a real payoff.

Layer three: shelves, or pages worth quoting

Engines quote passages. A page that never states a clean, extractable claim gives an engine nothing to lift. The pattern that works is a category hub, honest comparison pages, short answer paragraphs that stand alone without their surrounding context, FAQs, and a named author with a real profile behind the name.

The discipline here is negative rather than positive: only build the shelf for categories where you are genuinely strong. A page that overclaims does get retrieved, and then you are cited badly, which is worse than not being cited. We have turned down shelf-building work for exactly this reason more than once.

Layer four: placements, the main lever

This is where the budget should go, and it is the part most agencies skip because it is slow and cannot be shipped from a code editor. Ahrefs looked at roughly 75,000 brands and found brand mentions correlate with AI visibility at r = 0.664, while backlinks correlate at 0.218. Brands with independent media coverage are cited far more often than brands relying on their own pages.

Read that as correlation, because that is what it is. Well-known brands get both more mentions and more AI visibility, and the study cannot separate the two. But the direction is consistent enough, and the mechanism is plausible enough, that spending on third-party presence rather than on link buying is the better bet with the evidence available.

The practical method is to map, not guess. Run your buying prompts, record which domains the engine actually cites for your category, and treat that list as your target list. The sources an engine already trusts are not always the ones you would have picked.

One caveat on listicles

Analysis by Peec across roughly 200,000 answers found that being first in a listicle associated with a large visibility difference. That result is observational and everyone quoting it as a tactic is overreaching. More importantly, more recent model versions have started cutting listicle citations, so a placement strategy built entirely on roundups is fragile. Mix media coverage, review sites and directories deliberately.

What does not work, with sources

Two things dominate competitor decks and neither survives contact with the data.

llms.txt - Ahrefs examined 137,000 domains and found 97% of these files received zero requests. Retrieval bots made up about one percent of the small remainder. Google has said it will not use the file. Ship one in ten minutes if it makes someone happy; do not put it on an invoice.
General schema markup as a citation lever - across 1,885 pages Ahrefs found no citation effect. Specific Product and Review markup with real prices does matter. Everything else is entity hygiene, which is worth doing for a different reason at a different price.

How to measure without fooling yourself

Model answers are not deterministic. A single run of a single prompt tells you almost nothing, and any before-and-after built on single runs is noise dressed as a result. The workable method is a fixed panel of buying prompts, three runs per prompt, the same engine, recorded identically before and after.

Recall prompts - 'best X for Y in 2026'. Four or more, because this is what you are actually buying.
One brand prompt - 'is X legit, what do you know about them'. This measures entity health.
Citation prompts - 'how do I do Z'. These measure whether your content gets quoted at all.
Record three things per run: were you named, in what position, and which sources the answer cited.

Timeline expectations, honestly

The lag from a placement going live to it showing up in answers runs roughly four to eight weeks. That means a thirty-day engagement ends before the first real signal arrives. It also means that if someone shows you a dramatic before-and-after after three weeks, they measured noise. Plan in quarters or do not start.

What we would tell you not to buy

If your crawler is blocked, buy one afternoon of firewall configuration and re-measure in six weeks before spending anything else. If your site is a client-rendered app serving empty shells, buy prerendering and nothing else. If you are not genuinely strong in the category you want to be named in, buy product work rather than visibility work, because being cited for something you do badly is a liability.

We ran this whole pipeline on our own properties before we sold it to anyone, including the parts of the report that were uncomfortable to read. If you want the same diagnostic run on yours, the audit is at /geo and it stands alone - the findings are yours whether or not you continue with us. Ivan / 2pizza.team

Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.

What Does an AI Automation Agency Actually Do?

2pizza.team — Sun, 20 Sep 2026 13:00:10 +0000

TL;DR: the label covers four very different businesses. The one you want ships to production and can show you a system running right now. The single most useful question you can ask is what happens when the automation breaks at 2am, because only one of the four kinds has an answer.

The term did not exist a few years ago and now there are thousands of them. A large share are one-person operations that learned Make from tutorials and put 'agency' on a landing page. A smaller share are engineering teams building systems that run a business. Both use the same words on their websites and the output is not comparable.

I run one of these, which you should factor in. What follows is the version I would want if I were buying, including the parts that are inconvenient for me to write.

Four businesses, one label

Before evaluating anyone, work out which of these you are talking to. Each is legitimate for some jobs and wrong for others, and the confusion is where most bad engagements start.

The connector shop

Configures Zapier or Make flows between standard apps. Fast, cheap, genuinely useful for simple work. Cannot help you when the requirement outgrows what the platform does natively, and typically has no answer for error handling beyond what the platform provides. Right choice for a two-app flow. Wrong choice for anything your operations depend on.

The chatbot vendor

Sells one product, usually a support bot, configured to your content. Can be excellent at that one thing. Becomes a problem when the actual bottleneck is elsewhere and the answer is still a chatbot, because that is what they sell.

The consultancy

Produces strategy, process maps, a roadmap, and a recommendation to engage someone for the build. Valuable in a large organisation with real change management to do. In a company of twelve people it usually converts budget into a document.

The build shop

Designs and builds systems that run in production, including the unglamorous parts: retries, error handling, alerting, logging, and a handover. Costs more than the connector shop and delivers something you can rely on with money or with customers. This is the category worth paying for when the process matters.

What the work actually involves

A real engagement has stages, and the ones that get skipped are always the same ones.

Process analysis

Mapping what you actually do, not what the documentation says you do. This is where the surprises live: the step somebody added two years ago, the spreadsheet nobody mentioned, the customer type that gets handled differently for historical reasons. Half the value of a good agency is delivered here, before anything is built.

System design

Deciding which platform, which model, which integrations, and crucially what is deliberately left manual. Good design includes the decision not to automate something. If a vendor proposes automating 100% of a process on the first pass, they have not thought about the exception cases yet.

Build

The automations, the prompts, the integrations, and the error handling. The error handling is what distinguishes the price bands. A flow that works on the happy path can be built in a day. A flow that behaves correctly when the third-party API returns a 500 halfway through takes considerably longer and is the reason you are hiring someone.

Testing against reality

Not testing that the demo works. Testing with your actual malformed inputs, your duplicate records, your supplier who sends invoices as photographs. Anyone can pass a test they wrote themselves with data they chose.

Deployment and monitoring

Putting it into production with a way to see what happened and an alert when something did not. A system that fails silently is worse than no system, because you will trust it for the three weeks before you find out.

Handover

Documentation, access, and a named person who can change it later. This is the stage most commonly skipped and the most expensive to skip.

The questions that separate them

Ask these of anyone you are evaluating. What matters is not whether they have an answer, it is whether the answer is specific.

Can I see a system you built that is running in production right now, and can I speak to the client running it?
What happens when an integration fails at 2am? Walk me through it.
How do you find out something broke: does the system tell you, or does the client tell you?
What does the handover include, and who can maintain this if you disappear?
Who owns the accounts, the code and the data when this ends?
What did you get wrong on your last project and what did it cost to fix?

That last one is the most informative question on the list. Everyone who has shipped real systems has a story. Anyone who says nothing has gone wrong has either not shipped much or is not being straight with you.

Red flags:

Demos only in test environments, no live systems to point at
Promises to automate complex judgment-heavy work end to end
No documentation or handover plan in the proposal
Hourly billing with no fixed scope and no estimated total
Cannot explain what happens when the automation breaks
A maintenance retainer with no list of what it covers
Case studies with no client names, no numbers, and no way to verify them

What a sane engagement looks like

The shape is consistent across the good ones, whatever their size.

It starts with a process audit: a conversation where they map what you do, say what is automatable, and give a rough return estimate. This should cost nothing and take 30-60 minutes. If it costs money and produces only a document, you are talking to the consultancy.

Then a fixed-scope proposal: what gets built, what it will do, what it costs, when it lands. Variable scope with hourly billing can run indefinitely without a clear outcome, and the incentives under hourly billing point the wrong way for you.

On timelines: a focused automation for a single process should take two to four weeks to build and deploy. A system touching several departments takes four to eight. Anything quoted materially longer without a specific reason deserves a question, and anything quoted materially shorter usually means the error handling is not in scope.

What you should own when it is finished

This is the part clients most often discover too late, and it is worth putting in writing before anyone starts.

The accounts. The Make, n8n, OpenAI and Claude accounts should be yours, billed to you, not sitting inside the agency's workspace.
The code and the flows, exported and in your possession.
The data, in a format you can read without their tooling.
Documentation good enough for a competent third party to take over.
The prompts. They are part of the system and they are often where the real work is.

An agency that resists this is selling you a dependency rather than a system. There are reasonable middle grounds, for instance them holding operational access while you hold ownership, but the default should be that you can walk away and the thing keeps running.

What it costs and what that buys

Roughly: a single flow $500-1,500, a real business process $1,000-3,000, a reliable pipeline with an AI layer and error handling $3,000-8,000, a custom system replacing a back office $8,000-25,000. Running costs $50-200/month for most small businesses. The full breakdown, including the costs that do not make it into proposals, is in our pricing article.

When you do not need an agency at all

Sometimes the right advice is that this is not a purchase. If the job is one flow between two apps you already pay for, and someone on your team is comfortable with a bit of configuration, build it yourself in an afternoon. Make and n8n are genuinely approachable for that tier of work, and paying someone four figures to do it is paying for confidence rather than capability.

The line worth paying across is reliability. When the process touches money, customers, or compliance, and a silent failure would hurt, that is the point where the unglamorous engineering is the product and it is worth buying.

Our case studies are public with real clients, real stacks and real numbers. If you want to work out what your business actually needs, the audit at 2pizza.team/audit takes two minutes and no call.

Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.