Zoho Creator is a strong low-code platform. It’s also the wrong home for some things. The most useful thing anyone can give you isn’t another feature list — it’s a straight answer about where the boundaries are, backed by the platform’s own documented limits. So here’s the honest version: what Creator is genuinely good at, where it will hurt you, and a framework for deciding without a rebuild in your future.

Where low-code earns its place

Start with what Creator does well, because the case is real. You build web and mobile apps visually and add logic in a scripting language called Deluge. It consistently lands in Gartner’s Magic Quadrant for enterprise low-code platforms, positioned as a Challenger in recent years — below the Leaders (Power Apps, OutSystems, Mendix, ServiceNow, Appian, Salesforce) on the classic dimensions. But its recognised strengths — affordability, simplicity, and fit for departmental and mid-market workloads — are exactly the ones that matter for the workloads it suits.

Three categories where it’s often the right call:

• Departmental and operational apps. Inspection logging, field-service dispatch, approvals, asset tracking, intake forms — process apps that replace spreadsheets and email threads. Bounded, changing often, business-owned. Creator’s speed here isn’t hype; teams routinely ship in days what a traditional project takes months to deliver.
• Apps that need to be mobile on day one. Every Creator app is automatically a web app, a native iOS/Android app and a PWA from one build. If your workflow lives in the field, that’s a large amount of engineering you don’t have to staff.
• Anything deep in the Zoho or integration ecosystem. If the business already runs on Zoho, or the app mainly orchestrates other systems through APIs and webhooks, Creator’s connectivity is an accelerant rather than a constraint.

The through-line: bounded scope, high change frequency, business-owned logic, moderate data volumes.

That’s the sweet spot, and inside it the total cost of ownership is hard to beat.

Where it will hurt you, with the receipts

Now the part the demo skips. Creator’s constraints are real, documented and architectural. You can’t engineer around most of them — you can only design within them. Three areas deserve your attention before you commit a workload.

Data-heavy processing. Deluge is metered by statements executed, not wall-clock time, with a per-function ceiling roughly in the 5,000–50,000 range depending on plan. That sounds generous until you realise loops multiply. A for each loop whose body is eight statements exhausts a 5,000-statement budget at around 620 records. There’s no set-based UPDATE ... WHERE in native Deluge; you fetch and loop to modify records. And there’s no self-service database index — you request indexing from Zoho support for your most-filtered fields. Reports degrade at volume too: search-by-criteria options drop away past 10,000 records with a multi-select field, and bulk operations top out at 1,000 selected records. None of this is disqualifying for a 50,000-record operational app. For a high-volume transactional system doing heavy batch computation, it’s a wall you’ll hit in production after it passed in testing.

Concurrency and throughput. Beyond that per-minute throttle, the API path caps at six concurrent calls per account. For a widget-heavy or integration-heavy app under real concurrent load, that ceiling is a design input, not a footnote.

Governance and lifecycle. This is the one architects underweight. Creator gives you Development → Stage → Production environments on paid plans — a real SDLC framework. But published versions cannot be rolled back. There’s no Git, no branching, no merge, no CI/CD, and no built-in approval gate separating who edits from who publishes. Your release discipline has to be “fix forward,” your safety net is a backup taken before every production push, and your separation of duties has to be enforced organisationally, because the platform won’t do it for you. For a low-risk internal app, fine. For a regulated, audited, business-critical system, that’s a governance model you design around deliberately, not discover later.

The workloads to keep off Creator

Translating the above into a short “not here” list:

• High-volume transactional cores. Order processing at scale, ledgers, anything doing large batch computation on every run.
• Sub-second, high-concurrency public-facing apps where the throttles and concurrency caps become the user experience.
• Systems requiring formal, audited change control with enforced approval gates, rollback and source-control workflows out of the box.
• Deeply bespoke UX or algorithmic products where the visual builder and Deluge become a fight rather than a shortcut. At that point you’re paying low-code’s constraints without collecting its speed.

For these, a Leader-tier platform with a heavier engineering model, or a genuinely custom build, is the honest recommendation.

A decision framework you can defend

Skip the feature checklist. Ask five questions, in order:

1. What’s the data volume and processing shape? Thousands of records with light logic per operation: good fit. Hundreds of thousands with heavy per-run computation: pressure-test against the statement and report limits first.
2. Who owns the logic, and how often does it change? Business-owned and frequently changing rewards low-code. Engineering-owned and stable rewards traditional development.
3. What’s the concurrency profile? Internal team of dozens: comfortable. Thousands of simultaneous public users hammering workflows: model the throttles before you commit.
4. What governance does this workload legally require? If you need enforced approval gates, rollback and audit-grade change control, budget for the organisational process to supply what the platform doesn’t.
5. What’s the real total cost of ownership? Licensing is per user, and serious deployments often carry partner or implementation fees. Model TCO at your target user count and volume, not your pilot’s.

If the first three answers land in “bounded, business-owned, moderate-volume” and you’ve planned for four and five, Creator isn’t a compromise — it’s the efficient choice, and it’ll serve for years. If they land the other way, use low-code where it fits and route the hard workload elsewhere.

A mixed estate, with each workload on the platform that suits it, is a more mature architecture than forcing everything onto one tool.

The honest bottom line

Low-code isn’t a tier of seriousness. It’s a set of trade-offs. Zoho Creator trades away raw scale, self-service performance tuning and heavyweight lifecycle tooling in exchange for speed, low cost, and putting change in the hands of the people who understand the process. For a large share of enterprise workloads — the departmental, operational, integration-glue applications that make up most of any real portfolio — that’s a trade worth making, and the constraints only bite at genuine scale.

The architect’s job isn’t to be for or against low-code. It’s to know precisely where the line is, and to place each workload on the right side of it.