Short answer: for most internal business applications, up to a few dozen or a few hundred users, a no-code or low-code platform is faster and cheaper than custom development. You need custom development when an application faces heavy public traffic, has very complex logic, processes large volumes of data at once, or has to integrate deeply with many systems. So the question isn't which technology is "better", but which fits the task.
Two myths surround no-code and low-code. One says they're toys you can't build serious business systems with. The other says anyone can build anything with them, without technical knowledge. Neither is true. Several of our team's most important projects were built on such platforms, including replacing a large, complex SAP Emarsys setup.
What's the difference?
- No-code: the application is built entirely with visual tools, without programming: forms, tables, workflows, permissions, reports. Fast, but bound by the platform's limits.
- Low-code: visual tools, but extendable with code where needed. More flexible and suitable for more complex applications, but it requires developer skills.
- Custom development: everything from scratch, in code. The most flexible, but the slowest and most expensive, and maintenance is yours.
The line is blurred: many no-code platforms allow some code, and much custom development is built on ready-made building blocks. In practice it's a scale rather than three separate worlds. At one end are fully visual tools with no programming, at the other software written from scratch, and most business applications belong somewhere in between.
How big is the market?
According to Forrester, the market for low-code and digital process automation platforms stood at $13.2 billion at the end of 2023, and in its base scenario grows to about $30 billion by 2028. The same analysis says 87% of enterprise developers already use low-code tools for at least some of their work. This isn't a niche; it's one of the main directions of enterprise software development.
When no-code or low-code fits
An analysis by EY's Hungarian practice, using a simplified one-year total cost of ownership model, found low-code cheaper than traditional development up to about 70 users. In their example, for a 30-user application, a 4-month low-code build instead of a 12-month traditional build saves around HUF 13 million in developer pay.
The same analysis lists what low-code is not suited for:
- high-traffic public applications;
- processing very large numbers of rows at once (more than 4,000 in their analysis);
- very complex business logic;
- deep integration with many systems.
That's a good starting rule, but not set in stone. Besides the number of users, the platform's licensing model matters: some charge per user, others per application or by usage.
When you need custom development
- when the application is the product you sell to customers;
- when it must serve heavy, unpredictable public traffic;
- when the logic is so unique you'd have to force the platform with workarounds;
- when you must own the source code and can't tie yourself to a platform;
- when performance or security requirements exceed what the platform can deliver.
The UK government's purchasing guidance says custom development is justified when the need is unique or rare, few suppliers can meet it, products can't be adapted, and the organisation can manage the development. In that framing, a low-code platform is a middle way: the platform provides the backbone, the company the unique part.
What we've seen
Several of our team's flagship projects were built on such platforms.
Replacing SAP Emarsys. An electronics retail chain operating in two countries ran its marketing on a large, complex SAP Emarsys setup. We developed its own system on the ZEBEQ no-code platform, which replaced it in five months: campaign management, segmentation and customer communication now run automatically, with extended functionality and at lower cost. It shows that a no-code platform isn't only for small internal tools: it can replace enterprise software when the process is well described.
AI-based price monitoring. At a home furnishings retail chain we built a system on the same platform that tracks the prices, product data and promotions of 20 web shops and suggests prices. It went live in four months.
HR processes. At the local unit of an international fleet management company, HR processes that ran in spreadsheets moved into one system on ZEBEQ, with 70 users, in seven months.
Low-code examples. At the US subsidiary of an international animal health company, a vaccine production calculator was built on QuickBase (six months, 20 researchers and engineers), and across four European countries a mobile audit system on the OutSystems low-code platform, integrated with Bureau Veritas (eight months), where our team led development and provided project management and architecture.
The common lesson: a platform doesn't replace a good process description and good business analysis. The speed comes from not having to write the technical foundation, not from skipping the thinking.
Hidden costs and risks
Governance. If employees can build their own applications (citizen development), sooner or later you'll have thirty apps nobody knows about. Microsoft Power Platform's "managed environments", for example, provide sharing limits, data policies and release pipelines, but only with certain standalone licences. Governance has a price, and you need to plan for it.
Security. OWASP, one of the leading professional bodies for web security, maintains a separate risk list for no-code and low-code applications (the Citizen Development Top 10). Typical problems: overly broad permissions, hard-coded credentials, missing logging. A no-code app must handle permissions as carefully as a custom one.
Platform lock-in. If the platform's prices or terms change, switching is hard. Check up front how data and process definitions can be exported. That isn't a reason to avoid platforms, only a reason to read the contract and exit options as carefully as you would for custom development.
AI-assisted custom development isn't free either. Gartner warned in 2026 that AI coding costs may exceed an average developer's salary by 2028, and that most organisations can't yet measure business impact against that cost. "AI will write it" doesn't automatically make the custom route cheaper.
How to choose a platform
If you go for a platform, ask every candidate:
- What's the licensing model? Per user, per application or by usage? How does the price change if users double?
- How does it connect to your existing systems: ready-made connectors, a documented API?
- Where is data stored? If you need EU data residency, settle it up front.
- How does it handle permissions and logging?
- How can data and process definitions be exported if you want to switch?
- Who supports it, and how active is the community around it? Specialists for a rare platform are hard to find.
A good practice: have the same narrow, real process built on two platforms in a week or two and compare the results. Demos always look good; your own process quickly shows the limits.
Who should build it: your team or a partner?
No-code promises that employees can build their own applications. That works for smaller tools within one team. For business-critical systems, like a marketing platform or an HR system, it's worth combining the two: the company knows the process, an experienced partner brings the platform skills and good design.
The best setup is for the partner to build the backbone while training one or two of the company's key people, who can then make smaller changes themselves. That avoids full dependency while keeping the foundations sound.
What a good first version looks like
Whichever route you choose, the first version should be narrow and real. It covers one process end to end for one team, uses real data from day one, and has a clear owner who decides what goes into the next version. It doesn't try to replace every spreadsheet in the company at once.
In practice that means a first release within weeks on a platform, users testing it on their actual work, and a short list of improvements for the next round. If the first version takes six months before anyone uses it, the risk has already grown, whatever the technology.
Decision checklist
- How many users? A few dozen or hundred internal users: platform. Public, heavy traffic: custom.
- How complex is the logic? Forms, approvals, reports: platform. Complex calculations, real-time processing: custom, or low-code extended with code.
- How many systems to connect? A few, with documented APIs: platform. Many deep integrations: custom or low-code.
- How much data at once? Little: platform. Large bulk processing: custom.
- Do you need to own the code? If yes: custom.
- How fast do you need it? Weeks: platform. If there's time and money for the longer road: custom may be an option.
What to do now
- Write down the process the application is for, including common exceptions.
- Answer the six questions above honestly.
- If a platform is an option, look at two or three with the same process.
- Plan governance: who can build, who approves, how things go live.
- Check the exit path: data export, process definitions.
- Start with a narrow working version, and only then extend it.
If you'd like us to look at which route fits your process, and build it on ZEBEQ or another tool, have a look at our process automation, custom software development and business management (ERP) services.
FAQ
What's the difference between no-code and low-code?
On a no-code platform the application is built entirely with visual tools, without programming. On a low-code platform it's also visual, but can be extended with code where needed, so it suits more complex tasks.
Up to what size does low-code beat custom development?
EY's Hungarian analysis found low-code cheaper up to about 70 users in a simplified one-year model. More important: it's less suited to heavy public traffic, very complex logic and many deep integrations.
Can a no-code platform replace enterprise software?
Yes, if the process is well described and the platform can handle it. Our team replaced a large, complex SAP Emarsys setup with a ZEBEQ-based in-house marketing system in five months, at lower cost.
Are no-code applications secure?
As secure as they're built. OWASP maintains a separate risk list for them; the most common problems are overly broad permissions, hard-coded credentials and missing logging.
What's the biggest risk of no-code?
Lack of governance (lots of apps nobody knows about) and platform lock-in. Both are manageable if you set rules on who can build and check how to leave.
Sources
- Forrester – The Low-Code Market Could Approach $50 Billion By 2028
- EY Hungary – Programming without programming (in Hungarian)
- Microsoft Learn – Managed environments overview (Power Platform)
- OWASP – Citizen Development Top 10 (Low-Code/No-Code Top 10)
- IT Brief – Gartner warns AI coding costs may top developer pay by 2028
- GOV.UK – Define your purchasing strategy
