DEV Community: SaaS Glue

5 Integration Red Flags That Are Costing You Money Right Now

SaaS Glue — Tue, 29 Sep 2026 14:39:45 +0000

Key takeaways

If five people on your team spend 30 minutes a day checking another system, that's over $22,000 a year in salary spent on lookups, before counting the errors and delays those lookups cause
Integration problems rarely announce themselves. They hide in the reconciliation spreadsheet, and in phrases like "let me check the other system"
Each red flag on its own looks like a minor inconvenience. Together they're one problem: a workflow that only works because people carry data between systems
Fixing the root cause (the disconnect between your systems) is usually cheaper than paying for the symptoms, but not always. A workaround that runs a few times a week can be cheaper to keep

Most integration problems don't look like integration problems. They look like a busy team doing its best with a complicated process.

Nobody calls a meeting to announce "our systems aren't connected properly." What you hear instead is "I'll just check that in the warehouse system," or "the numbers should match by Friday."

The tricky part is how fast these problems start to feel normal. Copy data between platforms for two years and it stops feeling like a problem. It starts feeling like the job.

The hidden cost is still there, though. It's spread across dozens of small inefficiencies, each one too small to bother fixing, and somebody is still paying for all of them.

The five red flags below are one problem showing up in five places: a workflow that runs across several systems, with people carrying the work over the gaps. We call that human middleware.

If you recognize more than one, it's worth finding out what they're costing you. Not every one is worth fixing, and we'll get to which. And if one makes you wince, don't take it personally. Nobody designs a business this way. It piles up.

Red flag 1: "Let me check the other system"

Your sales team is on a call with a customer and needs to confirm stock. They minimize the CRM, open the warehouse management system, search for the SKU, and read the number back.

This happens several times a day, across several people. Nobody thinks twice about it, because it's always worked this way.

The cost of context switching between apps is higher than it looks. If five people on your team spend 30 minutes a day checking a second system, that's 12.5 hours a week of paid time spent on lookups. At $35 an hour, it comes to over $22,000 a year.

That's back-of-the-envelope math, on purpose. Swap in your own headcount and your own rate and see where you land.

McKinsey's research puts the wider picture higher still: knowledge workers spend nearly 20% of their working time hunting for internal information.[1]

And every lookup is a small window for error. The stock figure might be stale by the time they find it. The person reading it out might misread a field.

We worked with a wholesaler whose sales team had to leave their order management platform to check warehouse stock by hand before confirming anything to a customer. Log into a second portal, look the number up, come back, finish the order.

Orders still went out. Customers still got served. But the cost in time and accuracy was real, and it added up every day.

Once the systems were connected and stock levels flowed across on their own, the sales team stopped working as translators between two databases and went back to selling.

Red flag 2: Someone's job is mostly copying data between platforms

You have someone on the team, maybe in operations, maybe in finance, whose day revolves around a spreadsheet. Export from one system, tidy the columns, import into the next. Repeat until lunch.

They might be copying order details from your ecommerce platform into your fulfillment system, or retyping field reports into a central database. They're good at it, and fast. But they're doing work a properly connected system would handle in seconds.

Past the obvious salary cost, the errors add up in ways that are harder to see. One study put the error rate for manual data entry at roughly 1%, even under ideal conditions.[2] Process 2,000 records a month and that's 20 mistakes. If each one takes 30 minutes to find and fix at $35 an hour, you're spending over $4,000 a year on rework from a single process.

Each mistake makes more work downstream, too: a customer complaint, a return, a credit note, and somebody's afternoon spent working out what went wrong.

And because the person doing the transfer is usually the only one who really understands it, you've got a single point of failure. When they're on holiday or off sick, the process just stops.

One of our clients had administrators manually re-entering data from emailed field reports into their central system. The technician had already typed it all up once, in a Word template on site. Then someone in the office read it and typed it again.

Time-consuming, and completely avoidable. The information existed. It just wasn't flowing where it needed to go. Once reports came in through an app wired into their system, the retyping stopped.

Red flag 3: Monthly reconciliation because the numbers never match

At the end of every month, someone in finance or operations spends days, sometimes a full week, reconciling figures between systems.

The orders in your ecommerce platform don't match the orders in your accounting software. The warehouse's stock counts disagree with the website. Revenue in the CRM is a different number from the one your payment processor reports.

Everyone knows the numbers won't match, so reconciliation has become a scheduled ritual. Lock the door, open four tabs, and spend three days finding out why Shopify says 312 orders and Xero only has 308.

(The four orders do turn up eventually. Usually in the tab you checked first.)

Start with the labor. If one person spends three days a month reconciling, that's roughly $10,000 a year in salary alone.

The bigger damage happens between reconciliations. For a whole month the business runs on numbers that might be wrong, and decisions about purchasing, hiring, marketing spend and cash flow get made on data everyone already knows is shaky. The purchasing mistakes and late invoices from the other 27 days cost more than the reconciliation itself.

When systems aren't synchronized, discrepancies compound daily. One missed order becomes a stock discrepancy, which becomes a purchasing error, which becomes a fulfillment delay, which becomes a customer on the phone asking where their order is.

By the time the monthly reconciliation catches it, the damage is done and the trail's gone cold. Reconciliation fixes the numbers. It doesn't fix whatever broke them.

Red flag 4: Customers get wrong information because systems are out of sync

A customer orders a product your website says is in stock. The warehouse sold the last one this morning.

A client calls to check on an order, and your support team quotes a different delivery date from the one in the logistics system. Your marketplace listings show one price and your own website shows another, because the last update never made it to every channel.

Customer-facing data errors are the most expensive kind, because they cost you trust. Marketplaces keep score too. Amazon expects sellers to cancel under 2.5% of their seller-fulfilled orders in any seven days, and can deactivate them when they don't.[3] An oversold order usually ends as exactly that kind of cancellation.

The direct cost is easy to count. If an oversold order costs $40 in refund processing and you oversell ten times a month, that's $4,800 a year. But the customer who doesn't come back was worth far more than $40.

Every pricing mismatch chips away at a reputation you spent years building. Your customers have alternatives, and they'll use them.

A 3PL came to us about to lose a major client. The client needed to sell through Mirakl-powered marketplaces, and no off-the-shelf integration connected Mirakl to the 3PL's warehouse system. If the 3PL couldn't make it work, the client would move to a provider who could.

So we built the sync. Every time stock moves in the warehouse, the change flows through to every marketplace it affects, with a configurable buffer held back so a late update can't sell something that isn't there.

The client stayed. The overselling never started.

Red flag 5: You have built workarounds on top of workarounds

You know this one.

The Zapier automation that updates a Google Sheet, which someone checks every morning to decide whether to update the other system by hand. The email rule that catches order confirmations and forwards them to a shared inbox, where someone copies the details into the fulfillment queue. The workaround that was fine at 20 orders a day and now creaks at 200.

Each layer was a reasonable answer to a specific problem. Stacked up, they form a fragile patchwork that nobody fully understands and everybody's scared to touch.

Workaround debt is the integration version of technical debt, and it compounds the same way. Each new workaround is one more thing that can break, and it makes the eventual fix more expensive.

The more immediate problem is that workaround-driven processes fail in ways that are hard to spot. A Zap fails at 2am, and the order sits in the task history until someone notices and replays it. A webhook times out, and the retry never fires, because there is no retry. Or an order comes in with a field the automation wasn't built for, and it drops the record without telling anyone.

These aren't edge cases. They're Tuesday.

And they tend to surface at the worst possible moment, like Black Friday or the week a big new client goes live, when volume spikes past what the patchwork was built for and nobody has time to debug a Google Sheet. If any of this sounds familiar, we wrote about the specific signs you've outgrown low-code automation.

One ecommerce client's Royal Mail compensation claims ran entirely on a workaround. Xero can't search inside PDF attachments, so every lost parcel meant opening purchase orders one at a time and reading them, looking for what each item had cost. Some were scanned photocopies. At twenty minutes a claim and sixteen claims a week, that came to roughly 240 hours a year.

It takes about two minutes now. The hours came back, and a whole kind of work that should never have been manual went away with them.

Where all five end up

Live with all five long enough and you get something that isn't on any checklist, because it doesn't look like a problem. It looks like good management.

You open a report, and before you act on it, you check whether the numbers are right. You cross-reference the sales figure against the CRM and open the warehouse system to verify the stock count. Then you ask someone in finance whether the revenue number includes last week's batch of refunds.

You do this so routinely that it's stopped feeling like extra work. It's just "being thorough."

That's a symptom dressed up as diligence.

When a team treats its own reporting as unreliable by default, every decision takes longer than it should. Purchasing waits until someone "confirms the stock levels." Hiring slips a quarter because the revenue numbers "need to be validated first."

Five minutes of sanity-checking sounds harmless. Multiply it across every decision in the company and you get weeks of delayed action, compounding quietly.

If your team's default posture toward its own data is skepticism, don't blame the team. They learned it from the data.

What to do about it: a quick integration audit

If you recognized your business in more than one of those, you're not stuck. The cost of disconnected systems feels permanent because it's been around so long. It isn't, and fixing it usually costs far less than living with it.

Start small. Pick one process your team runs every day and follow it from start to finish. Watch where someone switches tabs, opens a spreadsheet, retypes something that already lives in another system, or says "hang on, let me check." Count the handoffs.

Even 30 minutes watching your order-to-fulfillment flow will turn up things nobody's questioned in years.

Then widen the lens. Walk through your other core processes (quote to invoice, customer inquiry to resolution) and note every point where someone copies data or waits on another platform. You'll probably find more handoffs than you expected. Each one is a candidate for automation.

Then quantify the cost. Time the manual steps, and count the errors that need rework. For the customer-facing mistakes, estimate what they cost you in revenue. You don't need forensic accuracy. A rough number is enough to justify doing something, and to decide which integration to fix first. If you want more structure, we published a five-step framework for calculating automation ROI with real numbers you can adapt.

Prioritize by pain. Not every disconnected system needs to be connected tomorrow. Start with the ones that touch money, stock or customers, because that's where errors cost the most and where automation pays back fastest.

A reality check: not every workaround is worth fixing right now.

If the process runs a handful of times a week and the manual cost is under a couple of thousand dollars a year, the integration will cost more than it saves. If the workflow itself is still changing (new tools, or a new business model), automating it locks in a process that might need to be different next quarter. And if the workaround is temporary on purpose, a bridge for three to six months while you validate a new approach, that's a sensible call.

The test is whether the workaround has outlived its justification. If it's been "temporary" for two years, it's furniture now.

And get the right help. Integration is a specialty. It shouldn't be a side project for your busiest developer. The gap between an integration that works on day one and one that still works on day three hundred is mostly unglamorous: proper error handling, and somebody watching for the day an API changes. If you're not sure where to start, we wrote about why small businesses benefit from a dedicated integration partner rather than trying to piece it together in-house.

Somebody on your team said "let me just check the other system" today, probably more than once. Nobody noticed, because nobody ever does. That's the trouble with all five of these: they sound like the job.

For now, they are the job. The workflow grew up around your team carrying data between systems, and today it can't run without them.

We built SaaS Glue around a simple idea: your team shouldn't be the integration layer between your tools, and we don't succeed unless you do.

If one of these sounded a bit too familiar, let's talk about fixing it.

References

[1] McKinsey Global Institute – "The Social Economy: Unlocking Value and Productivity Through Social Technologies" (2012). Found that knowledge workers spend nearly 20% of their time searching for internal information. The figure has been corroborated by subsequent research including Asana's Anatomy of Work Index (2023) and Coveo's Workplace Relevance Report (2023, survey of 4,000 employees), both of which found equal or higher figures. Available at: https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/the-social-economy

[2] Barchard, K.A. & Pace, L.A. – Preventing Human Error: The Impact of
Data Entry Methods on Data Accuracy and Statistical Results. Computers in Human Behavior,

Available at: https://doi.org/10.1016/j.chb.2011.02.004

[3] Amazon Seller Central – Cancellation Rate (CR) policy for seller-fulfilled orders: sellers should keep seller-cancelled orders under 2.5% of total orders over a 7-day period, and a higher rate may result in deactivation. Policy text as posted by Amazon staff in the Seller Forums; the full help page requires a Seller Central login. Accessed September 2026. Available at: https://sellercentral.amazon.com/seller-forums/discussions/t/fa2d8307-5daa-406c-a219-816d7da260b0

How Many SaaS Tools Does Your Business Actually Use? (It's Probably More Than You Think)

SaaS Glue — Fri, 25 Sep 2026 10:07:47 +0000

Key takeaways

A company with 75–199 employees uses an average of 44 SaaS applications[1]. Ask around before you count, and see what number comes back.
Workers toggle between apps roughly 1,200 times per day, losing about four hours a week just reorienting after each switch[2]
The subscription bill is the cheapest part of sprawl. The data silos and security blind spots underneath it cost more and show up nowhere
Cutting tools rarely fixes it. Fixing the workflows that run between them usually does, and the tools stay exactly where they are

Ask someone on your team how many software tools the business runs on. They'll probably say ten. Maybe fifteen.

Nobody has measured how wrong that guess usually is, so we won't pretend to. But the other half of the comparison has been measured, and it isn't close.

Productiv's 2024 data puts a company with 75 to 199 employees at an average of 44 SaaS applications.[1] BetterCloud's 2024 State of SaaS report put the average across all company sizes at 106, down from a peak of 130 in 2022.[3]

Both of those companies sell SaaS management software, so read the figures as a ceiling rather than a target. Even read that way, 44 is a long way from fifteen.

That gap has nothing to do with carelessness. Software gets adopted one team at a time, one problem at a time, and nobody anywhere is keeping a register.

What you don't know about, you can't manage. Every untracked tool is a billing line nobody reviews and a data silo that somebody on your team is quietly bridging with copy-paste. The industry calls this SaaS sprawl (sometimes app sprawl). Whatever you call it, if you haven't counted recently, you're living with more of it than you think.

Here's how to count what you've actually got, what the sprawl costs you in the places no invoice reaches, and which gaps are worth closing first. The counting takes an afternoon.

Where they all came from

SaaS sprawl doesn't happen because someone made a bad decision. It happens because everyone made a reasonable one.

Marketing needed an email platform, so they signed up for Mailchimp. Sales wanted a CRM, so someone started a HubSpot trial. Operations needed shipping labels, so they added ShipStation. Finance needed invoicing, so they set up Xero. Every one of those was the right call on the day it was made.

Nobody was looking at the whole picture, and most of the growth happens where the picture doesn't reach. Gartner puts it at 41% of employees acquiring, modifying or creating technology outside IT's visibility, rising to a projected 75% by 2027.[4] Big companies file that under shadow IT and staff a team to chase it. In a small business without a dedicated IT function, nearly everything is shadow IT, and the team chasing it is you.

There's no malice in any of it. The marketing intern signed up for Canva with the company card. Someone on the ops team started tracking projects in Notion. A developer spun up a Supabase instance for one workflow and moved on.

Nobody decides to own forty-four tools, in the same way nobody decides to own nine phone chargers. The pile just grows, and nothing ever gets thrown out. Three tools that do project management. Two that handle file storage. A handful of niche apps that one person uses for one task, which nobody else could name under oath.

How to audit your stack

The process is simpler than you'd expect. The results are less comfortable.

Start with the money. Pull twelve months of company card and bank statements, and write down every recurring charge from a software vendor. You'll find things you'd forgotten you were paying for.

Everybody does. The first count always comes in worse than the guess, and it comes in worst for the people who were certain it wouldn't.

Next, check your identity provider or SSO dashboard. Most small businesses don't have one, so look at the Google Workspace or Microsoft 365 admin panel instead. That shows which third-party applications have been granted access through OAuth, which is the "Sign in with Google" button your team clicks without reading. Zylo's 2025 SaaS Management Index found that organizations use just 47% of the SaaS licenses they pay for.[5] Less than half, across the whole stack. (Zylo sells a tool that finds idle licenses, so of course they would say that. Every company quoted in this article has a horse in the race, us very much included.) Canceling the idle ones is the fastest win an audit produces, and it usually pays for the afternoon you spent finding them.

Then the awkward part. Ask your team, and ask in writing so the answers are on a page rather than in a corridor:

What tools do you use every day?

What do you use a few times a month?

What do you pay for yourself and expense?

What are you using that you're fairly sure nobody else knows about?

People will name things that appear nowhere in your financial records. Browser extensions, freemium accounts, a trial from 2023 that nobody canceled. They all count, because they all touch your data.

Call them corridor tools. They live in one person's head and one person's browser, and the day that person leaves, they go quiet without anyone noticing.

Finally, sort the list by what each tool actually does. CRM, email marketing, project management, accounting, shipping, file storage, analytics. This is where the overlaps jump out. Two teams on two different project trackers. Three apps that can each email a customer. A spreadsheet doing a database's job because nobody knew the CRM already had that feature, which happens more than you'd think.

The hidden costs

The subscription bill is the visible cost, and Zylo's 2025 data puts average SaaS spend at $4,830 per employee per year.[5]

It's also the least interesting number, because almost nobody connects it to the work it's supposed to support. For one multichannel retailer we spread every recurring subscription across the orders it helped produce. A monthly bill nobody questioned became a cost per sale somebody could act on.

The operational costs are worse, and they compound quietly.

The big one is time lost moving between disconnected systems. A 2022 study published in Harvard Business Review tracked workers across three Fortune 500 companies and clocked roughly 1,200 toggles between applications in a single day. Twelve hundred! That worked out to four hours a week spent reorienting after each switch, or about five working weeks a year.[2]

In a small business it's worse than tab-hopping. The systems share no data at all, so on top of losing their place, people retype what the other system already knows. There's a reason "app fatigue" turned into everyday vocabulary on operations teams.

We see it constantly. One client had a sales team that left their order management system to check warehouse stock in a separate portal before every order, because the two tools didn't talk. Nothing dramatic ever went wrong. It was a slow, steady drain on time and accuracy that everyone had long since accepted as normal.

Security hides in plain sight too. Every tool that touches your data is a door into the building, and nobody has drawn the floor plan. You can't enforce a password policy on something you don't know exists. When someone leaves, their access leaves with them only in the sense that nobody revokes it. With Gartner projecting 75% of employees adopting technology outside IT's visibility by 2027,[4] that surface only grows.

Then there's onboarding. Every new hire has to learn a dozen tools, each with its own login and its own small ways of being weird. The onboarding period stretches, mistakes go up, and tribal knowledge becomes the only documentation that matters. When someone leaves, they take the understanding of how all the pieces fit together with them. You don't lose a person. You lose the wiring diagram.

Why "just use fewer tools" fails

Faced with a list that long, the instinct is to start cutting. Some consolidation genuinely does make sense.

All-in-one platforms like HubSpot or Zoho work well for businesses with straightforward workflows. If your needs are standard, one platform covering CRM, email marketing and basic automation is simpler to manage and cheaper to run than four best-of-breed tools you have to wire together yourself. Fewer vendors, and one support queue to shout at. We've watched that work.

That suitability has a ceiling, though.

The all-in-one that handles CRM, email marketing, project management and invoicing does each of them adequately and none of them well, which stops being acceptable the moment your requirements get specific. Your marketing team chose their email tool for its segmentation. Your operations team chose their inventory system because it handles multi-warehouse logic. Swap both for one platform that does neither properly and you've traded a sprawl problem for a capability problem, and customers notice the second one.

Here's the thing the count hides. A business running 100 tools that talk to each other is in better shape than a business running 15 where somebody spends every morning reconciling three of them by hand. Sprawl is the symptom you can see. The work happening in the gaps is what actually costs you.

So the more productive question is how to make what you already own behave like one system. When an order lands and stock updates across every channel on its own, and those changes reach your accounting platform without anyone touching a spreadsheet, you've solved the sprawl problem without deleting a single tool.

One client was spending 20 minutes on every lost-parcel compensation claim, cross-referencing their shipping platform against their accounting platform by hand. Both tools were fine. The gap between them was where 240 hours a year went.

Now the obvious disclosure: SaaS Glue does this for a living, so of course we lean toward "connect them" over "replace them." Weigh that accordingly. What we can tell you is which one sticks. Consolidation projects stall, because people fight to keep the tool that works for them, and they usually win. Workflow projects tend to land faster, because nothing changes for the person doing the job. Their screens stay the same. The data just starts arriving on its own.

What to fix first

You won't do all of it at once, and you shouldn't want to. The value of the audit is that it shows you where manual work and data mismatches are costing you the most. Start there.

Look for the places where a person is the middleware. Who is copying data out of one system and into another? Where does a process stall because the information lives in a tool the next person can't open? Where have errors crept in because something got re-keyed instead of synced?

Then rank by who finds out. Anything that touches money or stock goes first, because that's where a mistake stops being an internal annoyance and starts being a customer's problem. A broken sync between your store and your warehouse doesn't just confuse the office. It oversells stock you don't have, and the customer finds out before you do.

For lighter work (form submissions landing in a CRM, a Slack ping when a deal closes) Zapier or Make are perfectly adequate, and a great deal cheaper than anything we'd build you. Save the custom work for the connections where reliability actually matters, and where having someone who owns it long term changes the outcome.

Living with sprawl, deliberately

Sprawl isn't going away. Your SaaS bill went up last year, and so did everyone else's. Gartner forecasts SaaS end-user spending growing at nearly 20% year on year, with SMBs now projected to put more than half their technology budget into cloud services.[6] Next year you'll buy something else, because next year somebody on your team will have a problem that a monthly subscription solves by Friday.

The question is only whether it happens deliberately or by accident.

So put the audit in the calendar once a year, in the slot next to the insurance renewal, and let it be rough. A half-day that produces a categorized list of your tools, what they cost, who uses them and how data moves between them will tell you what to cancel and where the expensive gaps are. It will also tell you which corridor tools have quietly become load-bearing, which is worth knowing before the person holding them books a holiday.

Nobody needs a pristine, minimal stack. What helps is a stack you understand, where the workflows that matter run on their own and nobody is carrying data across the gaps by hand. Get that far and the count stops being a problem. It's just trivia about your own company.

The gaps between your tools cost more than the tools do.

We built SaaS Glue around one idea: your team shouldn't be the middleware between your software.

Once you've done the counting, the harder question is which of those gaps is worth paying to close, and in what order. We wrote that one out as a calculation with real numbers, and it's the sensible next thing to read if your list came back longer than you expected.

Two more this post left alone. If your plan for most of the gaps is "we'll just Zapier it," here's where that stops working. And once something is built, somebody has to own it on the Tuesday it breaks, which is the question nobody asks until asking gets expensive.

If you'd rather talk it through than read more of us, get in touch.

References

[1] Productiv – 2024 State of SaaS Trends: Growth. Available at: https://productiv.com/state-of-saas/2024-saas-trends-growth/

[2] Harvard Business Review – How Much Time and Energy Do We Waste Toggling
Between Applications?, 2022. Available at: https://hbr.org/2022/08/how-much-time-and-energy-do-we-waste-toggling-between-applications

[3] BetterCloud – 2024 State of SaaS Report. Available at: https://www.bettercloud.com/monitor/the-2024-state-of-saasops-report/

[4] Gartner – Managing the Risks of Shadow IT, 2022. Available at: https://www.gartner.com/en/articles/what-is-shadow-it

[5] Zylo – 2025 SaaS Management Index. Available at: https://zylo.com/reports/2025-saas-management-index/

[6] Gartner – Forecast: Public Cloud Services, Worldwide, 2024. Available
at: https://www.gartner.com/en/newsroom/press-releases/2024-11-19-gartner-forecasts-worldwide-public-cloud-end-user-spending-to-total-723-billion-dollars-in-2025

When Zapier Hits a Wall: Signs You've Outgrown Low-Code Automation

SaaS Glue — Mon, 21 Sep 2026 00:00:00 +0000

Key takeaways

Zapier, Make and n8n are the right first move for simple, linear workflows. Skipping them to build something custom is usually just an expensive way to be early
The breakpoints cluster in three places: logic too tangled for a visual builder, failures that nothing catches, and volume or cost outgrowing what the platform was priced for
OutSystems found that 65% of low-code projects eventually require custom code[4], which is a strange number for a company selling a low-code platform to publish
Outgrowing the tool happens one workflow at a time. Move the two that hurt and leave the other thirty exactly where they are

Zapier is a good product. So are Make and n8n.

Need new CRM contacts pushed into a mailing list, or a Slack message every time a form comes in? These tools have it working before lunch, with nobody's engineering time involved. More than 2.2 million businesses use Zapier.[1] That number isn't an accident.

So start there. Building something custom for a job a Zap would have done is a slow way to set money on fire.

There's a point where it stops working, though, and nobody announces it. Things just drift from "this is brilliant" to "this is held together with duct tape and prayer."

This is about where that point is, and how to tell you've reached it. Zapier gets named most often here because it's the best known, but the same ceiling hangs over Make, n8n, Power Automate, Workato and the rest of them.

And before any of it: if you've spent a month patching the same three Zaps and wondering whether you're missing something obvious, you're not. The tool is at its ceiling.

Branches on branches

"If this, then that" is fine. Every one of these tools does it well.

The trouble starts when the conditions begin depending on each other. Zapier has Paths, Make has routers, n8n has IF nodes, and Power Automate goes deepest, with its Condition and Switch controls. If you already run on Microsoft 365, that's the one to try first.

All of them branch. What none of them do well is branches that depend on each other.

Here's what that looks like on a real morning.

An order lands, and something has to decide which warehouse ships it. That depends on where the customer is. And on the product type. And on stock across three warehouses. And on the shipping method they picked. And on whether there's anything hazardous in the box.

Five inputs, each one changing what the others mean.

You can build that in a visual builder. People do. What you get back is a tree nobody can test, and nobody can safely change, because every edit risks a path they'd forgotten was there.

One client had a Mirakl-to-Mintsoft integration that split orders from several marketplace stores into sub-orders routed across several warehouse accounts. No arrangement of Zapier paths or Make routers expressed that cleanly, and the business rules kept moving anyway.

Step dependencies break in a quieter way.

Creating a fulfillment order needs an order ID from the store, a warehouse code based on current stock, and a shipping rate from the carrier. The first two can happen at once. The third has to wait for both. If either one fails, the whole thing has to stop rather than carry on with half the data.

Low-code platforms run on a pipeline. Step one, then step two, then step three. There's no clean way to say "wait for both of these, and abandon everything if one falls over," so you end up splitting the work across several Zaps that trigger each other by webhook. Now you've got three things to monitor instead of one, each with its own way of going quiet.

What happens at 2am

Things fail. Constantly. APIs return 500s, auth tokens expire mid-sync, webhooks time out, data arrives malformed. Nobody's software is at fault here. That's just Tuesday.

So the interesting question is what happens in the ninety seconds after.

What you want is retry logic that knows the difference between "try again in ten seconds" and "stop, this will never work." Somewhere to park the items that failed for good, so nothing vanishes silently. A cutoff that stops hammering a service that's already struggling. And an alert that tells you which of those just happened.

No platform in this category hands you all four. With enough scaffolding you can approximate two.

Zapier auto-retries some errors and keeps a task history you can replay by hand. Make does better, with separate routes for different error types. n8n goes furthest here: its Error Trigger node lets you build a whole second workflow just for failures.

Each one raises the ceiling a bit. Whether that's high enough is a question about your workflow rather than about the logo on the tool.

The manual replay is where it really bites. The Uptime Institute's 2024 outage analysis puts roughly 60% of IT downtime down to human error during manual processes.[5] Replaying failed tasks by hand before your first coffee is exactly that kind of process.

When an order sync fails at 2am and the retry logic is "someone checks the error log in the morning," you aren't automated. You're semi-manual with extra steps.

Webhooks make it worse, because they're fire-and-forget by design. The sending system dispatches the event and forgets you exist.

If your endpoint is down when Shopify sends an order, that order doesn't arrive late. It doesn't arrive. And if two webhooks land out of sequence, you can process a shipment update for an order that hasn't been created yet.

Handling that properly means holding events in a queue and remembering which ones you've already processed. That's a piece of engineering, not a setting.

One request per hour

We built an integration for a client whose warehouse system accepted one request per hour. One! Not one per second. Per hour.

We spent the first afternoon assuming we'd misread the docs.

There's no setting for that in Zapier. What it needs is a queue that holds work, releases it on a schedule, remembers what it already sent, and survives a restart without double-shipping anything.

That's a few hundred lines of code and a database table. It isn't a checkbox.

That one's extreme. The everyday version is milder and far more common. A downstream service allows 60 requests a minute, Friday afternoon sends 200 orders at once, and the platform's built-in retry starts politely hammering an API that's already saying no.

Every API has limits, and low-code platforms stack their own on top: polling intervals, task caps, execution timeouts, and concurrency limits you don't get to set. For most workflows that's fine. For anything time-sensitive or high-volume it's the whole game.

Nobody agrees what an address is

Systems don't agree on the shape of data, and they never will.

Your store keeps an address as one string. Your warehouse wants five fields. Your accounting tool insists on ISO 3166-1 alpha-2 country codes, and your shipping provider wants the country spelled out like a human would. One system sends dates as Unix timestamps. The next expects ISO 8601 with a timezone offset.

Low-code tools map fields and reformat text, which covers a surprising amount of this. Zapier's Formatter handles the simple cases. Make's transformation tools go further. n8n lets you write JavaScript in a Function node.

Then you hit something like this: look up this SKU in system B to get the variant ID, use that to query system C for the current price, apply the customer's contract discount, and hand the result to system D.

That's a data pipeline. Building one inside a visual editor produces something fragile and genuinely miserable to debug.

The code block tell

Every one of these platforms now ships an escape hatch. Code by Zapier. Custom modules in Make. Function nodes in n8n. Custom connectors in Power Automate. They exist because the vendors know the visual builder runs out.

Reaching for one is the clearest signal you've outgrown the tool.

When you're writing fifty lines of JavaScript into a text box with no version control, no tests, no way to run it locally and no way for a colleague to review it, what you've got is a custom integration in the worst editor ever built for one.

One or two code blocks patching an edge case, though? Fine. Genuinely, don't worry about it. But when the workflow is mostly code blocks held together by a visual editor, you're paying for the constraints of low-code and the maintenance burden of custom code at the same time.

Finding out from a customer

The message usually looks something like this:

Hey, is the stock sync running? Shopify says we've got 4 of the black ones, the warehouse says 0, and there's a customer on the phone.

By the time that arrives, it's been wrong for a while.

Low-code platforms give you task logs and an email when something fails outright. That catches the loud failures, and the loud failures are the easy ones.

It's the quiet ones that cost you. A partial failure that only hits orders with two shipping addresses. A field that started arriving empty three weeks ago. Accuracy eroding a percent at a time, with nothing ever bad enough to set anything off.

You can't set up an alert in Zapier that says "average sync time has doubled this week," or "stock levels in these two systems have drifted more than 5% apart." Those are precisely the signals that catch a problem while it's still small and boring.

We've had clients find inventory mismatches weeks after the sync started drifting, because it never technically failed. It just started being slightly wrong, and nothing was watching for slightly.

In low-code you get two states. Everything is fine, and something broke loudly enough to send an email. There's a lot of room between those, and that's where the expensive things live.

The task meter

Zapier charges by the task, and a task is any action step that succeeds. Triggers are free. So are filters, paths and Formatter steps. Everything that actually writes something somewhere is not, so a Zap with four action steps, running 1,000 times a month, costs 4,000 tasks rather than 1,000.

The arithmetic surprises people. The Team plan is $69/month for 2,000 tasks, and that's the price if you pay for the year up front. Month to month it's $103.50.[2] A shop doing 500 orders a day, with a stock sync and a shipping update and an accounting entry on each one, is running about 45,000 tasks a month. Twenty-two times the allowance, on a setup nobody would call complicated.

If Zapier has started feeling expensive for what it does, that's the reason. The pricing was designed around simple automations, and you're running a business through it.

Make and n8n price high volume more kindly. But cost isn't the only thing volume does to you.

Push thousands of operations a day through a visual workflow engine and it sags. Execution times stretch. Queues back up. The platform becomes your bottleneck, and your options for fixing that are whatever the vendor decided to expose.

Somebody else's servers

Everything so far has been about what the tool can't do for you. This one is about where your data sleeps.

Connect an app to a cloud-hosted low-code platform and you've handed that platform's infrastructure a key to your system. Your credentials and your data both pass through a third party.

For a Slack notification, who cares. For customer financial data or health records, it's worth a minute's thought. Self-hosting n8n removes the third party and hands you the uptime and the security patching instead, which is a real trade rather than a free win.

This matters more than it did two years ago, because of where the data goes next. Businesses are running AI workflows that push customer data through LLMs, and plenty of those route through Zapier or Make on the way.

So customer data transits a third-party platform, possibly getting logged or cached, before it reaches an AI provider whose data handling you also have to take on trust. Two hops outside your control.

With a custom integration you can run a local model inside your own VPC, and the sensitive parts never leave the building.

Neither GDPR nor SOC 2 requires that, to be clear. Both are perfectly satisfiable with third-party processors, the right contracts and some paperwork. What owning the infrastructure buys you is a shorter list of people you have to trust, and a much shorter audit.

43% of data breaches involve small and medium-sized businesses,[3] and a platform holding credentials for thousands of companies at once is a target worth somebody's effort.

The pattern

Every one of those is the same shape. The platform handles the first ninety percent beautifully and gives you almost nothing for the last ten.

The last ten is where your orders live.

Low-code vs custom at a glance

	Low-code (Zapier / Make / n8n)	Custom integration
Logic	Branches, painful once they interact	Nested conditions, parallel steps, async
Error handling	Auto-retry, manual replay	Backoff retries, failure queues, alerting on both
Data	Field mapping, basic formatters	Full validation, schema enforcement, multi-system lookups
Monitoring	Task logs, email on failure	Threshold alerts, dashboards, drift detection
Volume	Task-based pricing, bottlenecks at scale	Hosting and upkeep to pay for, but flat against volume
Custom code	Code blocks with no versioning, tests, or review	Full dev environment, version control, CI/CD
Security	Credentials on third-party platform	Credentials in your own infrastructure
Speed to launch	Minutes to hours	Weeks
Best for	Simple, linear, non-critical workflows	Business-critical, complex, high-volume workflows

Where low-code wins

None of this is an argument for ripping out your Zaps. Most of them are doing their job perfectly well, and over-engineering something that works is its own kind of expensive.

If a workflow is linear, low-volume, and nobody's day is ruined when it fails, low-code is the right answer. Notifications. Contacts syncing from a CRM into an email tool. Form submissions landing in a spreadsheet. Social posts going out on a schedule. When the worst case is that someone hears about a new lead an hour late, the whole risk calculation is different.

Platform-native tools can beat general ones outright on their own patch. Shopify Flow handles tagging and inventory alerts inside Shopify more cleanly than any general-purpose tool manages.

Worth saying plainly at this point: we build custom integrations for a living, so "build something custom" is the conclusion we're financially inclined toward. Weigh it accordingly.

If your workflow fits in a Zap, we'll say so, and not out of virtue. A custom build for a job Zapier already does costs more and hands you one more thing to maintain.

Most businesses end up running both, and that's the right outcome rather than a compromise. Low-code for the simple things. Custom for the handful where reliability actually matters. The only skill involved is being honest about which pile a workflow is in, especially when it's quietly moved from one to the other.

How to tell

The signs cluster, and no single one of them decides it.

You spend more time maintaining an automation than it saves you. You've got a Zap that fails often enough that replaying it by hand is part of someone's morning. There's a chain of automations triggering each other and nobody can draw it on a whiteboard. Your plan cost is climbing toward what building the thing would cost. Or you've got business logic living in a Google Sheet, because no low-code tool would take it.

Three or more of those and you've outgrown low-code for that workflow. Three is a rule of thumb rather than a finding. Any one of them on its own can be lived with, which is exactly why they pile up without anyone calling it.

And it's a verdict on that one workflow, not on your stack.

The move doesn't have to be dramatic, and it shouldn't be. Pick the workflow causing the most pain, build a proper replacement for that one, and leave everything else exactly where it is.

One client came to us over their Royal Mail compensation claims, which needed AI invoice parsing and cross-system correlation before anything could be bundled into evidence. No sequence of Zaps was ever going to hold that. Everything else they were running stayed put, and still is.

A focused integration for a single workflow usually takes four to five weeks. Something spanning several systems might run to a few months. We build the monitoring first, before the thing it's monitoring, so you can watch it working from the first week rather than taking our word for it.

Low-code earned its place. It let a generation of businesses automate without hiring anyone, and most of what it's doing for you right now should carry on doing it.

Starting there is smart. Staying there after you've outgrown it is where the cost turns up, usually as somebody's morning.

We built SaaS Glue around one idea: your team shouldn't be the middleware between your software.

If you haven't counted how many tools you're gluing together yet, that's the cheaper thing to do first. And if you already know which workflow hurts, the next question is whether fixing it pays for itself, which we worked out with real numbers.

Otherwise, tell us what keeps breaking and we'll look at it with you.

References

[1] Zapier – About Zapier. Available at: https://zapier.com/about

[2] Zapier Pricing, accessed September 2026. Available at: https://zapier.com/pricing

[3] Verizon – 2024 Data Breach Investigations Report. Available at: https://www.verizon.com/business/resources/reports/dbir/

[4] OutSystems – The State of Application Development, 2024. Available at:
https://www.outsystems.com/1/state-app-development-trends/

[5] Uptime Institute – Annual Outage Analysis, 2024. Available at: https://uptimeinstitute.com/resources/research-and-reports/annual-outage-analysis-2024