Someone spends ten minutes explaining numbers that already exist in three different systems. Someone shares their screen. People ask clarifying questions.

Eventually the meeting actually begins.

We point to situations such as this one as examples of poor organizational communication. In many cases, though, the problem isn’t communication at all.

It’s a systems design problem.

Organizations often talk about systems replacing meetings and human interaction. Sometimes they should. Sometimes they shouldn’t. And sometimes the system shouldn’t replace interaction at all; it should simply record what actually happens in the real world.

The real design question isn’t whether systems eliminate human interaction. It’s which interaction should exist in the first place.

Some interaction is necessary because people are reasoning together. Other interaction exists only because information hasn’t been made visible yet.

Good systems eliminate the second kind.

Too many systems get this wrong.

Subscribe now

When a System Should Replace Human Interaction

Some conversations and meetings happen only to transfer information.

Consider a hypothetical team that runs a weekly service health review.

Before a shared monitoring dashboard existed, engineers gathered information from Slack threads, incident tickets, and deployment logs. Someone assembled a summary of outages and errors before the meeting and presented it to the group.

The first part of the meeting was always spent reviewing what had happened.

Which services went down?
How long were they unavailable?
What was the severity?

Although people were talking, most of the meeting involved transmitting information that already existed somewhere.

After the team implemented a shared incident dashboard, the structure of the meeting changed. Incidents appeared automatically in one place. Severity levels were visible. Resolution times were tracked. Anyone could review the data before the meeting began.

The meeting itself didn’t disappear, but its purpose shifted. Instead of recounting incidents, the team discussed patterns. Why were certain failures recurring? Were there architectural weaknesses behind them? Which services needed deeper attention?

The system didn’t eliminate the meeting, but it eliminated the need to explain the same information repeatedly.

When interaction exists only to convey information, a system should usually replace it.

When a System Should Support Human Interaction

Not all interaction is informational.

Some interaction exists because people need to interpret situations, apply judgment, or make decisions under uncertainty.

In those cases, replacing the interaction would be a mistake.

What the system should do instead is support the interaction by giving people a shared view of the situation. When everyone enters a discussion already looking at the same information, the interaction improves immediately. Participants arrive prepared. Assumptions get challenged earlier. The discussion can move directly to reasoning.

In this role, the system isn’t replacing human interaction. It’s enabling better interaction.

When Systems Drift From Reality

There is a third situation that appears frequently in operational systems: the system attempts to represent reality but slowly drifts away from it.

Consider a conference room reservation system.

On paper it solves a simple coordination problem. Employees reserve rooms through a calendar, and the system tells everyone which rooms are available.

In practice, the real world rarely aligns perfectly with the system. People reserve rooms and never show up. Meetings run long. Teams use empty rooms that were technically booked by someone else.

The calendar might say the room is reserved until two o’clock, but when someone walks past the room it is empty.

At that point people stop trusting the system. Instead of checking the calendar, they ask each other whether the room is actually free.

The system still exists, but it is no longer authoritative. Interaction returns because the system no longer reflects reality.

This pattern appears across many operational systems. Whenever a system drifts away from reality, people fall back to human interaction.

A Better Mental Model

One useful way to think about systems is to separate intent from reality.

People are good at describing what they intend to do. Systems coordinate processes. Automation is good at recording what actually happens.

A simple mental model is this:

People record intent.
Automation records reality.

Consider a delivery company.

A dispatcher schedules a route and assigns deliveries to a truck. That step records intent; it describes what the organization plans to do.

Reality is recorded automatically. The driver scans the package when it arrives. GPS records the truck’s location. The system logs the delivery time.

Now the system can show both things clearly: what was supposed to happen and what actually happened.

When reality is captured automatically, the system stays trustworthy.

When systems rely on people to manually report reality after the fact, accuracy tends to decline.

Why Systems Often Fail

Many enterprise systems quietly assume that people will faithfully maintain data about the real world.

In practice, they rarely do.

Sales activity tracking provides a common example. A company might require salespeople to log every call and email in a CRM in order to create visibility into sales activity.

But the actual work happens elsewhere. Calls happen on the phone. Conversations occur in email threads and messaging apps.

Logging the activity becomes a separate task.

At first people try to keep the system accurate. Over time entries become rushed or incomplete. Some activities are never recorded at all.

Eventually the system stops reflecting what actually happened. Once that happens, people stop trusting it.

The system was designed for reporting rather than for the work itself.

Replace Interaction Only When the Process Is Clear

Systems should replace human interaction when the interaction exists only to transfer information and the process itself is well understood.

If the rules are clear and the outcomes can be modeled in the system, automation works well.

But much of real work does not fit that pattern.

When processes are new, complicated, or ambiguous, human interaction matters. When decisions depend on judgment or intuition, discussion is essential.

In those situations the system should record the outcome of the interaction rather than attempt to eliminate it.

The Problem With “Single Source of Truth”

Enterprise architecture discussions often revolve around the phrase “single source of truth.”

In practice, that phrase often implies that other systems contain incorrect or outdated information. One system is considered authoritative while others may drift.

We should aim for something better.

The goal should not be a single location where truth resides. The goal should be systems designed so that the truth stays consistent everywhere.

Achieving that requires thoughtful synchronization and discipline about how many platforms hold critical data. When done well, systems reinforce each other instead of contradicting each other.

Designing Systems That Stay Close to Reality

Systems that support good decisions tend to follow a few simple principles.

Real-world actions should connect directly to system actions. Work should not happen in one place and then be reported somewhere else later.

Whenever possible, systems should observe events automatically rather than relying on manual updates.

Exceptions should surface quickly. When reality diverges from expectations, the system should make that visible.

And perhaps most importantly, systems should avoid asking people to maintain data that the system could capture on its own.

The Real Question

The question isn’t whether systems should replace human interaction.

The question is whether the interaction exists for information or reasoning.

If it’s information, systems should replace it.

If it’s reasoning, systems should support it.

And when reality changes, automation should record it.

As a long-time Zoho developer, I’ve spent years working in Deluge—writing scripts, automating workflows, integrating APIs, and sometimes even pushing the platform to its limits. Deluge is powerful, but if you've ever bumped into its constraints or tried to build something a bit more complex, you’ve probably felt that itch for something more. That’s where Catalyst comes in.

Catalyst is Zoho’s full-stack serverless platform. And while it’s incredibly powerful, much of the content out there focuses on individual use cases. What’s missing is a bridge—a way for seasoned Zoho developers to comfortably step into Catalyst and see how familiar principles apply in this broader, more capable environment.

That’s the gap I want to help close.

Subscribe now

Why Move from Deluge to Catalyst?

If you're like me, you probably started your Zoho development journey trying to solve every problem in Deluge. And for a long time, I saw that as a badge of honor. But I've shifted my mindset: I don’t have to live like Catalyst doesn’t exist.

Here’s the thing—Deluge is meant to extend the functionality of Zoho apps. It’s great for automating actions within CRM, Creator, Books, and so on. But it has limits. Catalyst lifts many of those limits while keeping you in the Zoho ecosystem.

Instead of struggling with long, complex Deluge functions, or awkward workarounds for limits like execution time or external libraries, you can just use Catalyst. And in doing so, you’re still operating in Zoho’s privacy-centric cloud, still close to your CRM data, still in the world your clients trust.

What’s the Same?

You’re already serverless.

That may sound odd, but it’s true—writing Deluge in CRM or Creator is a serverless act. You don’t manage infrastructure; you just write logic and it runs. That same mindset applies in Catalyst. You’ll find yourself more at home than you might expect.

Catalyst, like Deluge, is event-driven. You respond to triggers (like a field update) and execute a function. The difference? You now have full access to modern languages (Python, Node.js, Java), scalable architecture, and far better observability and testability.

What’s Better in Catalyst?

Here’s where things get exciting:

• Scalability without limits: Execution limits like those in Deluge? Gone.

• External libraries: Need a date recurrence engine? Pull in a Python package and get it done in five lines.

• True parallel environments: Develop and test in dev, push to production when ready.

• Observability: Logs that actually tell you what happened.

• Cost: It’s pay-per-use and very cheap. Most of my production Catalyst setups cost under $10/month.

And then there’s complexity. You can build layered, asynchronous logic that would be nightmarish in Deluge but elegant in Catalyst.

Catalyst Architecture 101

Catalyst uses a microservice, event-driven architecture. This means:

• Each function is single-purpose and disposable.

• Functions communicate via events (like a record being edited or a value being cached).

• The state of your app exists across various services—caching, file storage, databases—not necessarily in one place.

• You should lean into the tools Catalyst gives you, rather than rebuilding everything in code.

Here’s the mindset shift: In Catalyst, the cloud is the application.

How to Trigger Things

You have a lot of options to start your logic in Catalyst:

• API Gateway: Build APIs to call from CRM, Creator, or anything else. This is my go-to.

• Event Listeners: Listen to changes in CRM or internal Catalyst events.

• Job Scheduler: Schedule logic to run later or repeatedly.

• Signals: Use template-based data transformation and external API interaction with minimal code.

• Direct Function URLs: I recommend avoiding these—API Gateway gives you more control and security.

Writing and Organizing Code

You’ll write functions in Python, Node, or Java. I prefer Python—it’s fast, readable, and Catalyst supports it well.

There are two function types to know:

• Basic functions: Ideal for most workflows.

• Advanced functions: Use these if you need direct HTTP control (e.g., return a 404, redirect, etc.).

For orchestrating multiple steps, Catalyst offers Circuits. Think of these like flowcharts for your backend logic: wait, branch, retry, batch, and so on.

💡 Pro tip: If you're polling an API every 30 seconds, don’t write a loop in code. Use a Circuit with wait steps. Lean into the platform.

Managing State and Data

Serverless apps struggle with state, but Catalyst gives you tools:

• Cache: For short-lived, small data. Lightning fast and great for coordination between functions.

• Relational DB: Best for app settings or persistent metadata.

• NoSQL DB: Fast, flexible, and surprisingly powerful once you get it.

• File Storage: Great for holding large blobs of data temporarily (e.g., JSON results from another API).

• Environment Variables: Per-function, so use them sparingly. I recommend encrypted storage in the DB for secrets instead.

Designing for Concurrency

Serverless is inherently concurrent. That’s a strength—but it’s also a challenge.

To avoid issues:

• Design idempotent logic: Hitting an endpoint twice shouldn't break anything.

• Pull fresh data right before final writes, if there's a time gap.

• Use queuing structures like Job Scheduler or Event Listeners if things must run in order.

Conclusion

Zoho Catalyst isn’t just an alternative to Deluge—it’s the natural next step when your automation needs outgrow the scripting layer. And the good news? You already have the mindset to succeed.

If you’re a Zoho developer looking to level up your automation, embrace complexity, and build apps with modern tooling—all while staying inside Zoho’s ecosystem—Catalyst is worth learning.

Start with one thing. One script. One function. Then build from there.

Got questions or want to dig deeper? Reach out—I’d love to hear how you’re using Catalyst.

To meet this demand, vendors have developed two seemingly competing solutions: low-code and serverless computing.

Low-code is all about making app-building accessible to business users. You don't need to write thousands of lines of boilerplate code to create something useful. Instead, you pick and place the pieces you need, and you can build something great in much less time.

Serverless computing attempts to solve technical overhead and therefore speed and cost by solving a different problem. Serverless platforms provide a series of web services that take the place of a server, so the application owner does not have to maintain it. Instead of building an application from the ground up, serverless-oriented engineers cleverly bridge together various web services into their own microservices. They layer custom code on top of this robust platform for application development. For all this, the owner of the application pays according to the usage of the platform.

These may seem like two different strategies, catering to two different audiences. But my professional experience over the past few years has shown me that the two, when leveraged together, form one of the most compelling application development stacks available today. Mark Troester had this idea a few years ago as well and wrote a compelling argument about why they should be leveraged together here.

By looking at these two ideas, we're not just talking about new tools. It's more about thinking differently on how we make apps. It's about making it easier for anyone to bring their ideas to life and not get bogged down by the technical bits. So, let's dive in and see how these two can change the game together.

The rise of Low-Code

The popularity of low-code platforms is soaring, reshaping how we think about building apps. Gartner, a well-known market research firm, has spotted this trend too. They predicted that by 2024, almost 65% of all app development will happen on these user-friendly platforms. I'm hopeful that we get a retrospective on this soon to see where the industry is at today in 2025 relative to this prediction. Certainly the rise of LLMs has eaten up much of the conversation. Nevertheless, low-code applications are used on a daily basis in many organizations.

Low-code platforms make creating apps much easier. They use simple, drag-and-drop interfaces that don't require you to write a lot of complex code. This opens up app development to everyone, not just the people with technical skills. They're called citizen developers, and they're changing the game because now anyone with a good idea can build an app.

This ease of use does more than just lower the barrier to entry; it sparks innovation. When more people can develop their ideas quickly, there’s more room for creativity and new solutions. Organizations can adapt faster and come up with unique answers to problems, which is a huge advantage in today’s fast-moving digital world.

My Journey with Low-Code and Serverless

I have been working professionally as a developer, building custom extensions and applications on the Zoho platform, since 2020. In that time, I've come to realize that most of what Zoho offers is essentially a platform for low-code development. In fact, many other software tools could be looked at as low-code development tools, not only applications that are explcitly labeled as such. If you can customize a layout, present and store data, and build in a custom application layer using scripts, webhooks, drag and drop workflows, or anything like that, you are definitely in the realm of low code.

Around the same time I started working in Zoho, I earned an AWS Solutions Architect Associate certification. I did so because I had an interest in cloud computing and I knew that the career prospects were good. At first, I did very little with this, but as I build more and more complex applications using Zoho tools, I saw a gap that could be filled by AWS. The environments for code execution in low-code applications are not very robust. You tend to write code in more of a scripting style that can be very difficult to maintain. You also face various limitations to the execution such as time and number of lines executed. You typically cannot import libraries and are limited to the operations availabe to you in that environment. Therefore, as more complicated needs would arise, I would look to a serverless back end over which I had more control, with integration by HTTP calls to custom APIs of my own design. Since 2022, my platform of choice for this work has been Zoho Catalyst.

Low-Code Meets Serverless

There is great power in the fusion of low-code with serverless. A developer or small team can rapidly build an application on a low-code platform, leveraging a serverless full-code back end when facing limitations of the low-code platform. Low-code makes the application development easy and accessible. You don’t have to be a coding expert to create something useful, and many complete applications can be built on these platforms only. The serverless computing layer will give the application additional horsepower when necessary, and much like most low-code platforms you don’t want to worry about keeping computers running all the time just for your app to work. Serverless computing automatically adjusts resources for your app as usage fluctuates.

Zoho is my Platform of Choice

Now, even though I'm open to chatting about all sorts of platforms, Zoho is my main ingredient. I work with it professionally, so when we talk about making apps, I'll often talk about how it’s done using Zoho's tools. It's like my go-to toolbox. And just so you know, I also have a secondary toolset; I can work with AWS (which is another big, powerful set of tools for building and running apps).

Zoho is really stepping up its game by mixing serverless development with its low-code offerings in Catalyst. Zoho's move means if you have some serious coding chops, you can dive in and do even more complex, powerful things, while still enjoying the simplicity of Zoho's take on the serverless experience.

Please Subscribe for More

As we wrap up, I want to extend an invitation to all of you to continue this conversation on our Substack. Your experiences, insights, and contributions are the keys to evolving our standards and practices in the world of app development. So, don't hold back! Share your journey, tips, and thoughts with me. Together, let's pave the way for an even brighter future in application development.

Subscribe now