Low-code development means building applications with visual designers, ready-made components and configuration, writing code only for the parts that are truly unique.
You drag a form together, define a data model, draw a workflow and publish. What you then have is not a prototype but a working application with user management, permissions, logging, a mobile version and hosting around it.
What it is not: a way of building software without anyone who understands software. That promise is often made in the market, and it does not hold. Low-code removes the writing of standard code, not the thinking about data models, processes, permissions and support. Skip that, and you quickly build something that becomes unmaintainable just as quickly.
Saying that honestly makes the rest of the story stronger, because the real benefits are big enough.
The time saving is not in the typing. An experienced developer writes code very quickly. The saving is in everything you do not have to build.
On top of that, you can show something much earlier. In a custom development project you only see something working after months; with low-code, after days. That difference is not just pleasant but reduces risk, because ninety per cent of the misunderstandings in software projects only come to light when someone sees the screen.
Login and password reset, roles and permissions, a database set-up, form validation, search and filtering, reporting, export, audit logging, a mobile view, hosting, backups, monitoring and a deployment pipeline. In almost every application that is seventy to eighty per cent of the work, and it is the same work in every application.
What you build is the twenty per cent that sets your organisation apart: your data model, your process, your screens, your rules.
| Low-code | Custom development | |
|---|---|---|
| Time to first working version | Days to weeks | Months |
| Standard functionality | Built in | Build it yourself |
| Making a change | Hours to days | Sprint and release |
| Who can contribute | Business and developers | Developers only |
| Hosting, backup, scaling | Part of the platform | Set up and manage yourself |
| Security baseline | Maintained platform-wide | Your responsibility |
| Continuity risk | Low; more people can work in it | High with a single developer |
| Freedom in UX and architecture | Limited by the platform | Unlimited |
| Cost at the start | Low | High |
| Cost over time | Licences per user | Maintenance and hosting |
A few of those points deserve some explanation, because they usually get little attention in sales pitches.
A partner who only lists the advantages is selling itself. These are the situations in which we recommend custom development.
Zoho Creator is strong when you need a clearly scoped application built around data and forms: a registration system, a request process, an inspection app, an inventory module, an internal request portal. You build forms, reports and workflows visually, using the Deluge scripting language for the parts that go further.
The biggest advantage comes if you already work with Zoho: your application shares user management and data with your CRM, Desk, People and the rest of the suite. A request that comes in through Creator can go straight to a deal or ticket, without an intermediate integration.
Creatio is the choice when the process leads rather than the data. You build complex workflows with branches, approvals, exceptions and several departments visually in BPMN, with the Freedom UI designer for the screens around them.
Because BPM is at the foundation of the platform, the diagram and the execution remain the same thing. Change the process model and the behaviour changes with it. That is valuable for processes that change regularly.
| Your question | Most likely |
|---|---|
| A registration or request application with forms and reporting | Zoho Creator |
| A process with approvals across several departments | Creatio Studio |
| An app that works closely with your Zoho environment | Zoho Creator |
| A process you want to be able to adjust regularly | Creatio Studio |
| A field service or inspection app with offline use | Zoho Creator |
| Process monitoring, lead times and case management | Creatio Studio |
In practice the choice usually follows from what you already have in place. If you already work in Zoho or in Creatio, it is rarely worth debating.
Instead of an expensive custom project, we had a working application within a few weeks. We now make changes in days, not months.
This is the promise that has given low-code a bad name with IT departments, and rightly so.
What is true: someone from the business can change a form, add a field, build a report or move an approval step. That is a real gain, and it is exactly why you choose low-code.
What is not true: that you can set up an application without expertise and have it still be right three years from now. Designing the data model, designing permissions, thinking through what happens with exceptions, setting up integrations, testing and arranging support: that remains skilled work. Low-code does not change what you need to think about, only how much you have to type afterwards.
The sensible division we recommend: we lay the foundation and set up the first version, your team manages and extends it, and we come back for integrations, larger extensions and periodic maintenance. That way you keep the speed of low-code without the mess that arises when everyone just builds whatever they like.
What needs to happen, for whom, how often, and what are the exceptions? It often turns out that part of it can be solved with standard features in software you already have. You can also book a standalone process mapping workshop for this.
Is there already a package that does this? Then building is rarely wise.
Before we make any screens.
So misunderstandings are cleared up before they become expensive.
Where needed. See also application integrations.
Including agreements on who is allowed to change what.
For extensions and for the moments when the platform is no longer enough.
Low-code does not earn its place because it is cheap, but because you find out sooner whether you are building the right thing, and because you can keep adapting it afterwards without every change becoming a project.
That makes the most important question at the start not "which platform", but "what will this look like in three years, and who will maintain it then". A partner who only talks about speed has not asked that question.
We work with Zoho Creator and Creatio, and we also build custom software when low-code is not enough. Precisely because we do both, we can give honest advice on which way to go.
No-code works entirely with visual tools and is aimed at users without programming knowledge; the limit of the platform is the limit of what you can do. Low-code uses the same visual approach but lets you add code for the parts that are unique. In practice the two terms are used interchangeably: most platforms that call themselves no-code offer a scripting or API layer somewhere.
In the build phase almost always, because you do not have to create the foundation. Over time it depends on your user numbers: low-code usually charges licences per user, while custom development has maintenance and hosting costs. With a limited number of internal users low-code wins comfortably; with thousands of external users the sums can tip the other way. Always calculate for your expected size in three years.
For changes, certainly: adding a field, changing a form, creating a report, moving an approval step. Setting up a new application requires expertise in data modelling, permissions and support. The workable division is that we lay the foundation and your team then manages and extends it.
That is a normal moment, not a failure. Usually you solve it with an integration to an external system or with a piece of custom code within the platform itself. If that does not work, it is time to build that part outside the platform and connect it. What you need to watch out for is piling up workarounds: three exceptions to an exception is the signal that you are building in the wrong direction.
There is platform dependency, to be honest. The picture is more nuanced than often claimed, though: custom development is also tied to frameworks, cloud providers and the knowledge of whoever built it, and with custom development that dependency is often tied to one person rather than to a platform with a partner network. What limits the dependency is a clear data model, exportable data and documentation.
A clearly scoped application with forms, workflows and reporting is usually ready within a few weeks, most of which goes into the analysis and the data model. An application with several roles, complex processes and integrations with existing systems takes several months. The difference with custom development lies mainly in the moment you see something working: days instead of months.
Zoho Creator when the application revolves around data, forms and reporting, and certainly if you already work with Zoho: your app then shares user management and data with the rest of the suite. Creatio Studio when the process leads: workflows with approvals, branches and exceptions across several departments, and case management for files without a fixed path. If you already work in one of the two, that is usually the deciding factor.
The security baseline is usually stronger than with self-built software, simply because the platform supplier maintains authentication, encryption, permissions, logging and certification platform-wide. What you need to watch yourself is the configuration: role-based access, retention periods, the data centre region and who is allowed to build. For organisations with strict requirements, that last point (governance over who may create applications) matters more than the technology.
Tell us about it.
