Make, Zapier: Bubble?

No-code solutions lean on integration adhesives. Is it a healthy dependency? Or one to be concerned about?

Years ago, I was asked to unwind a deep dependency on Zapier. It was a mess. There were 250 Zaps, each doing things that overlapped in several cases, and the company had no documentation about them. The naming of the Zaps could have been more helpful, and more than 50% (it was thought) had some business logic embedded in them. More than 200 had business logic, and fifty contained copies of algorithms that were core to their competitive posture and considered trade secrets.

The incentive to unwind this massive collection of automation and application glue was triggered by a single oh-crap moment — their venture capitalist wanted to understand the topography of the intellectual property she was about to invest in.

This is an extreme example, but it is neither uncommon nor do I believe that such a dependency on platforms like Make and Zapier is rare, especially in no/low-code solutions.

Make, Zapier, and the many similar competitive platforms have proliferated astoundingly. You can’t visit a no/low-code community forum without seeing significant activity discussing these services as ideal pathways to quick and effortless integration and automation.

Airtable’s community mentions Zapier on more than ten thousand pages, roughly one in five conversations compared with the ubiquitous term “table”. Make (formerly Integromat) cannot be measured because the name “Make” is considered by most search engines as a stop word. Given that Make is vastly more popular with Airtable solution builders, these no-code integration tools likely represent more than a third of all conversations among developers.

Bottom line - the dependency is vast, and it’s only going to grow. AI will ensure this.

No one can deny, that no/low-code platforms are the future of semi-custom software solutions. I've always admired Zapier and Make as engines of innovation for domain experts. They serve to eliminate integration friction, and now, with generative AI, we can look forward to a massive uptick in new dependencies on platforms that provide integration adhesives.

And this makes me nervous.

Since the emergence of the no-code trend, we've been plowing business logic and our most precious automation and process advantages into systems like Zapier. Is there a bubble here that we’re not able to see? Is there a total cost of ownership issue that we’re glossing over? Are there added security attack surfaces? And how does an enterprise monitor multiple automation layers in a moderately distributed no-code solution?

Phil Lakin suggests Operator Platform may play a key role in wrangling the complexities and added risks (if any). I haven’t checked it out, but this looks like a tool designed to help companies avoid getting sideways with integration glue factories that make it effortless to create a very big mess.

Perhaps I'm irrationally fearful, but I know from experience that unhealthy dependence on third-party integration services prevents solution makers from establishing a clear title for their creations. On this dimension alone, I advise anyone building a solution or service to carefully weigh the risks of long-term dependencies for integration and automation features.

Setting Aside IP

Let’s put a pin in the IP risk of using third-party integration and workflow platforms. What else could backfire when building so much of your cool no-code app in these tools?

Fractured Business Logic

Skilled BPM (business process management) workers probably freak out when they realize how no-codeists work. The advantage of a BPM platform is its unified management and structure. Perhaps NoCodeOps is simply the future of BPM, and we haven’t consciously thought it all through yet.

If you’re scattering your solution’s key business logic, you best document the crap out of this activity because it will someday boomerang to haunt you.

True Cost-of-Ownership

Pro-glue factory consultants are quick to tout the benefits in sales pitches and social media posts but rarely mention the costs. The costs are both monetary and non-monetary. Invariably, the use of these automation platforms raises the true cost of owning and maintaining a no-code solution in both dimensions. And those costs are always moving upward. It takes more time to manage something that naturally grows, and it takes more money as the dependencies grow horizontally and vertically.

Security Attack Surfaces

I’m a complete idiot when it comes to security. However, I have learned that as the number of exposed web surfaces increases, so do the security risks. Moving your data and workflow instructions through a third party has to be more risky. Indeed, some rewards accompany this risk, but it often means spreading your secret API tokens far and wide. Just sayin…

Uptime Monitoring

As you spread a system's services and critical operations across independent platforms, monitoring all of them in a unified view becomes difficult. Creating alerts and notifications is more complex and needs to be addressed. You become blind to parts of the application machinery. Most use email alerts for significant issues, and email is where knowledge goes to die.

Downtime Remedies

When a platform (like Airtable) is down or struggling to perform, workflow automations fail. If the automations are integral to the core platform, they stop running. This contrasts with external platforms that chug along without error handling or prescribed caching so that transactions can pick up where they left off. Your only out is to build self-healing automation and workflow systems, a difficult proposition.

Integration Atrophy

This issue comes in two distinct untasty flavors -

1. Workers who build automation and integration workflows have left or are promoted.
2. Solution specifications change without notice.

One thing is certain — the workers who built your Zapier recipes will not be there when you need them most.

No/low-code systems are among the most likely to change frequently because they make it easy to apply new optimizations quickly. A field name changes, and suddenly, your Make recipe stops running. There are ways to mitigate this risk, and books like Automate It with Zapier and Generative AI could help. However, can you avoid all the edge cases that could take down a system when [seemingly] simple modifications are applied to your no-code platform?

Setting Aside Everything

Anytime we concentrate control or power over our information, we see conflict, higher costs, and unanticipated outcomes. Many outcomes are positive. Some are negative. Airtable’s recent pulling of the rug has caused countless companies to seek alternative solutions. Google has killed products with millions of users because they can. The concentration of power makes this possible.

We are aggressively ceding control of our no-code business process engines. I’m not intimating that the glue factory providers may act against our best interests. However, the concentration of data flows and automations for almost every no-code app into the hands of a few organizations seems like fertile ground for future calamities, not unlike the challenges we see with big tech companies today.

Maybe We’ve Got It Upside Down?

Is it possible that we haven’t realized what Make and Zapier will become over the horizon? Will they transition into the central place where you begin to build your no-code solution? Are database platforms going to transition from SaaS to PaaS?

Footnotes

"Unwinding" - The idea of unwinding this dependency and possible remedies is a very complex conversation. But, there are ways to mitigate and entirely remove such intertwined reliance on these services.

"Domain Experts" - Domain experts are the people who know their craft exceedingly well and benefit from no/low-code platforms to innovate in ways that even the best engineers and IT teams cannot.

"Glue Factory" - Integration and automation adhesive platforms like Make and Zapier. This is not intended to be a derogatory term; it is simply a brief handle for a class of tools.