The six ceilings of no-code — and what gets built above them

The thesis is simple, and falsifiable: every documented limit of a no-code tool points to the architecture layer that comes after it, and reading it before building costs less than discovering it in production. Data volume, API throughput, logic, permissions, observability, reversibility: the six ceilings below are published by the vendors themselves, on dated pages. None of them is a secret.

This is ordinary engineering practice: a cloud provider publishes its quotas, a database its connection limits. No-code platforms do the same. The difference: their users, often business teams, rarely read the limits page before committing.

These no-code limits don't say "don't use the tool." They say where the tool stops by design — and where the next layer begins. Across the thirty-plus projects we have delivered, the recurring starting points — a spreadsheet used as a database, dashboards sent as email attachments, six systems that never talk to each other — were all written down somewhere (Ownward internal data, 2026).

Volume is the most legible ceiling. Airtable publishes its tiers: 1,000 records per base on Free, 50,000 on Team, 125,000 on Business; beyond that, Enterprise Scale is negotiated. Notion bounds its API payloads: 1,000 blocks and 500 KB per request, 2,000 characters per rich text item.

Throughput is less visible but sharper, because it often applies regardless of plan.

The observable signal: 429 errors, syncs that stretch into hours, scenarios cut off mid-run. The pattern is not to rewrite everything: it is to move high-volume flows to a dedicated engine. We operate a mapping-driven sync engine — Python orchestrated on Trigger.dev, configuration stored in Airtable — connecting 6 CRM/ERP systems to a single source of truth; a new source means a new mapping, not new code (Ownward internal data, 2026). The switching criteria are detailed in when to industrialize an automation.

Every visual execution environment bounds what a process can do:

• Zapier sets a maximum of 100 steps per Zap, paths included;
• Airtable's "Run a script" automation action executes within 30 seconds, with 512 MB of memory, 50 fetch requests, and output capped at 6 MB;
• on the Softr side, an Airtable table connects to one block at a time.

These bounds protect the platform and all of its customers; they also draw the tool's natural perimeter. The signal: workflows artificially split to fit under the limit, scripts that time out on large batches.

The pattern doesn't require leaving the tool — that's what this ceiling illustrates best. In one year, we shipped 17 custom Airtable extensions to production (React and Tailwind, inside the base itself), including a complete CRM: Aircall telephony, templated emails, SMS and WhatsApp, interactive maps (Ownward internal data, 2026). The team stays in its tool; complex logic lives in code deployed on top. That is the no-code to pro-code continuum in the literal sense: not a border to cross once and for all, but layers that coexist.

A collaborative tool's permission model is calibrated for collaboration, not fine-grained confidentiality. Airtable's documentation states it plainly about field and table editing permissions: "these permissions don't control who can see data, only who can edit it". Restricting editing and restricting visibility are two different problems — and the second belongs to the layer above.

The same boundary line shows up at Notion: whole-workspace PDF export is reserved for the Business and Enterprise plans there — and the vendor has announced its retirement on August 31, 2026. At every vendor, fine-grained governance is a plan-graded capability, not a default setting.

The observable signal:

• bases duplicated "so everyone only sees their part";
• hand-filtered exports;
• dashboards circulating as email attachments.

Two patterns, lived. For edorma, a weekly dashboard maintained by hand every Monday became a multi-tenant SaaS isolated by Postgres row-level security: visibility is guaranteed by the database, not by user discipline. For a CFO portal, dashboards sent by email became a Next.js/Supabase portal with Google SSO and visibility by email or domain (Ownward internal data, 2026). When the question becomes "who sees what, and how do we prove it?", the answer is an authentication layer and a database that enforces the rules.

The last two ceilings are the least known, because they block nothing day to day. Observability first:

• Zapier keeps Zap history 29 to 69 days by default on all plans;
• Make keeps its logs 7 days on Free and 30 days on the paid plans displayed;
• at Airtable, audit logs are reserved for the Enterprise Scale plan, with 180 days of retention. The signal always arrives too late: an incident detected after the retention window leaves no trace.

Reversibility next. Airtable's CSV export works view by view: only visible values come out; comments, field descriptions and extension data stay in the tool, and exported attachment URLs expire within a few hours. Notion exports an entire workspace on all plans, but the operation can take up to 30 hours and the link expires after 7 days.

The common pattern: a data repository that lives outside the tool of use, continuously synced. Tools remain interfaces, the repository is the source of truth — the structural answer to the five forms of vendor lock-in.

What doing nothing costs — An incident discovered beyond the retention window gets reconstructed without logs: 29 to 69 days of history by default at Zapier, 7 to 30 days of logs at Make (as observed on August 12, 2026). An Airtable Free base that hits its quota of 1,000 API calls per month puts every connected tool on hold until the 1st of the following month. Every ignored ceiling gets paid for at the moment you have the least room to choose.

A no-code ceiling is managed like any architecture constraint: a signal, a pattern.

These figures are living pages: verified on August 12, 2026, they evolve with the vendors — any architecture decision deserves a re-read of the source pages on the day itself. Enterprise plans are negotiated, and their real ceilings are not published. Above all, clearing a ceiling with code has a cost: building, maintenance, skills to assemble. For many teams, a plan upgrade pushes the wall back by years, and the upper layer would be premature. Finally, six ceilings form a reading grid, not an exhaustive taxonomy: compliance and per-seat cost are others, covered separately.