The platform cannot do that
"The platform cannot do that, we will have to solve it differently", after which the customer adapts their process to the software instead of the other way round.
Zoho Catalyst is Zoho's pro-code development platform. Read what it is, when to use it, and why so few partners in the Netherlands work with it.
At some point in almost every implementation comes the question that decides everything: "can it do this too?" A calculation that is just slightly different from the standard. An integration with a system no connector exists for. A portal where customers need to do something no module supports. Documents that have to be generated and checked automatically.
With most partners, one of two answers follows.
"The platform cannot do that, we will have to solve it differently", after which the customer adapts their process to the software instead of the other way round.
"We will build that outside it", after which a separate system appears with its own database, its own login, its own administrator and an integration nobody will understand in three years' time.
There is a third answer, and it is called Zoho Catalyst. We give that answer, and we are one of the few in the Netherlands who do.
Catalyst is Zoho's pro-code development platform: a fully fledged cloud environment on which you build your own applications and services, within the same ecosystem the rest of your Zoho environment runs in.
It is not a low-code tool and not a configuration screen. It is a development platform with serverless functions, databases, object storage, authentication, caching, job scheduling and a range of AI services, on which you build in languages such as Node.js, Java and Python.
Everything is billed by usage, with a free development environment to get started.
This is not modesty but a factual observation about the market, and it explains why you will not find information about it with many other providers.
Most of the Zoho partner market consists of configurators. That is no criticism: configuring Zoho is a craft, and for most organisations it is exactly what they need. But it is something different from building software. A configurator knows modules, fields, workflows and blueprints. Catalyst calls for developers who can reason about data models, API design, error handling, scalability, security and maintenance.
That combination (deep knowledge of the Zoho platform and a real development team) is rare. Companies that can build are usually not in the Zoho ecosystem; companies that know the ecosystem usually do not build.
Mobile XL sits at that intersection. We have been implementing Zoho for years, and we also have a development department that builds custom applications, integrations and portals. That means that when that one question comes up ("can it do this too?") we do not have to sell a no, nor propose a separate system.
A few types of solutions we use Catalyst for, so you get a picture of where it fits.
A customer, supplier or partner portal with its own logic, its own screens and its own permission structure, that still works on your Zoho data. Not as a separate system but as part of your environment, with the same users and the same security.
Older industry packages, government portals, supplier environments and machines. With serverless functions you build the translation between two systems including error handling, logging and retries: something an off-the-shelf integration rarely does neatly.
Reading incoming PDFs with OCR, validating the content against your own rules, and posting the result in the right Zoho module. With SmartBrowz the other way round too: generating documents.
Price calculations with dozens of variables, planning algorithms, capacity calculations, scoring models. Things you cannot fit into a configuration screen without making it unreadable.
Processes that handle thousands of records a night or take too long for a standard workflow, with job scheduling and monitoring around them.
A predictive model on your own data via QuickML, or AI components you call from your own screens instead of having to accept them as they come out of the box.
What the standard software could not do was built on Catalyst and feels like one whole with the rest of Zoho. Our customers do not notice where one system stops and the next begins.
You mainly recognise a specialist by the fact that they know when not to use their own tools. Catalyst is powerful and therefore tempting, but it is rarely the first answer.
| Your question | Where it belongs |
|---|---|
| An extra field, a different workflow, an approval step | Standard configuration in the Zoho app itself |
| A well-defined internal application with forms and reporting | Zoho Creator (low-code) |
| An integration between two modern systems with good APIs | Zoho Flow or an integration platform |
| A bot that carries out actions in a system without an API | RPA |
| An AI agent within your existing processes | Zia Agents |
| Your own logic, your own data model, your own screens, on your Zoho data | Catalyst |
| An application completely separate from Zoho | Your own stack, not necessarily Catalyst |
Our order is always the same: first we check whether it can be done as standard, then whether low-code is enough, then whether an integration solves it, and only then whether something needs to be built. Custom work is more expensive to make and more expensive to maintain. Anyone who does not tell you that honestly is selling themselves instead of the solution.
The reverse is also true: there are cases where cramming everything into standard features ends up costing more than building. A workflow with fifty branches that nobody dares to touch any more costs you more than a clean application with documentation.
What needs to happen, for whom, and how often? This conversation often already shows that half of the question can be solved with standard features.
What does it cost to build, what does it cost to maintain for five years, and what is the alternative?
This is where custom projects succeed or fail.
So you see what you are getting before it is finished.
You must be able to move on without us. A custom solution only we understand is not a solution but a dependency.
Monitoring, error handling, logging and an agreement on who takes a look when something breaks. That last point is where many custom projects in the market still fail. Building software is the easy part; keeping software running for five years is the work.
Most organisations choose a Zoho partner based on the implementation they have in mind right now. That is understandable, but it is the wrong question.
The better question is what happens in eighteen months, when your environment is up and running and you hit the first real limit. Can your partner move with you then, or do you have to bring in a second party that does not know your environment? That second scenario is where landscapes fall apart: two parties, two responsibilities, and a customer stuck in between as soon as something does not work.
We offer both from one team. Configuration where possible, low-code where it fits, and pro-code on Catalyst where it is really needed, with one point of contact and one party responsible for the whole.
A pro-code cloud development platform from Zoho on which you build your own applications and services. It offers serverless functions, databases, object storage, authentication, caching, job scheduling, browser automation and a range of ready-made AI components. You build on it in languages such as Node.js, Java and Python, and it runs within the same ecosystem as the rest of your Zoho environment.
Zoho Creator is low-code: with visual tools you build well-defined business applications with forms, workflows and reports, without in-depth development knowledge. Catalyst is pro-code: a fully fledged development platform for developers, with complete freedom in data model, logic and architecture. Creator is faster and cheaper when it fits; Catalyst is the choice when you run into the limits of low-code.
Probably not, and we would rather say so straight away. By far most questions can be solved with standard configuration, low-code or an integration. Catalyst comes into the picture for custom calculation logic, portals with specific requirements, integrations no connector exists for, heavy background processing or document processing at scale. Always start with the question of whether it can be done as standard.
You build on a Zoho platform, so there is platform dependency, just as with any other cloud provider. What limits that dependency is how you build: a clear data model, separation between logic and platform-specific parts, and documentation another team can read. We deliberately steer towards that, and we believe you should be able to move on without us.
The platform itself is billed by usage, with a free development environment, and at normal volumes it is not a big expense. The real costs lie in design, build, testing and management. That is why we test out loud beforehand whether building is the right choice: what does it cost to make, what does it cost to maintain for five years, and what is the alternative?
Yes. In practice it is often about existing separate systems that need to keep running but should be better integrated with the Zoho environment. Depending on the situation, we connect them, build a layer around them, or migrate the functionality step by step.
We agree that in advance. We deliver with documentation, monitoring and error handling, and you can choose management by us or by your own team. What we do not go along with is delivering a solution without it being clear who takes a look when something breaks: that is the most common reason custom work becomes a problem after a few years instead of a solution.
Because the combination of in-depth Zoho knowledge and an in-house development team is rare in the Netherlands. Companies that know Zoho usually do not build, and companies that build usually do not know Zoho. That means that with a question outside the standard we do not have to sell a no or propose a separate system, with one party remaining responsible for the whole.
Put it to us. Sometimes the answer is still "that can be done as standard", and sometimes it is exactly what Catalyst exists for.