What we learn by building

In 2025, half of IT projects run over deadline, budget or scope, and nearly one in five is abandoned. Yet every internal tool starts as if it were definitive. Owning the temporary — a no-code base built in days, designed to be taken down — remains the decision nobody dares to claim.

One model sells recommendations and leaves you to execute alone; the other sells execution and keeps its hands on every change. Neither is paid to make your teams capable. The missing category has one simple criterion: what you can do on your own when the contract ends.

An ERP that has run invoicing, inventory, and payroll for fifteen or twenty years makes every overhaul project look like a leap into the void. Public audits of large replacements put numbers on that void: over a billion dollars with nothing delivered in one case, a £90M overrun in another. The problem is not the legacy system; it is how you evolve it.

Every no-code tool publishes its limits: records per base, requests per second, script duration, log retention. These ceilings are not hidden flaws, yet teams often discover them in production, at the worst possible time. Reading them before building changes the architecture decision.

Connecting an AI assistant to a CRM, an ERP or a document base still means, in most organizations, one custom integration per tool-system pair. Ten systems and five AI tools: fifty projects to build, then maintain. An open standard offers a different arithmetic — provided you understand what it solves, and what it does not.

Tutorials wire a public front end straight to a no-code base's API. The setup works — until the documented 5 req/s per-base limit, pagination and attachment expiry catch up with it. Three architecture patterns answer, depending on traffic, required freshness and write direction.

The per-user monthly price is the only visible line of a SaaS subscription. Integration, training, administration, forced upgrades and exit costs pile on top, often without ever appearing in the budget. Most SMEs discover them at renewal, when it is too late to negotiate.

Six systems that never talk to each other, three API grammars, and every connection written by hand: each new source costs more than the last. The problem is not the amount of code — it is where the field correspondences live.

Software subscriptions pile up faster than anyone manages them: business units commit 70% of SaaS spend, and barely more than half of purchased licenses are actually used. Most leadership teams discover the true size of their application portfolio when the invoices arrive.

“We’ll do AI once our data is clean.” Yet only 7% of companies say their data is completely ready — and waiting doesn’t move that number. The prerequisite is a myth, and it has a measurable cost.

Five people edit, ninety-five just read — and all one hundred pay for a seat. On most public SaaS price lists, the occasional reader costs as much as a full user, and that price is often the least published on the grid. This imbalance can be measured, and it can be calculated.

A team's autonomy over its tools is usually judged by gut feeling: the provider “seems” less indispensable, the team “seems” more comfortable. Without metrics recorded before and after, there is no way to tell real progress from displaced dependency.

Business teams deploy no-code tools faster than IT can audit them. The result: personal data sitting in SaaS platforms where nobody knows where it is hosted, who accesses it, or how to get it out one day.

An Airtable base that works ends up feeding applications: a portal, a dashboard, a product. That is when the published API limits — 5 requests per second per base, 50,000 records on the Team plan — stop being footnotes. The bridge between Airtable and Postgres should be designed before you need it.

Cloud data egress is now free and EU law caps switching timelines and fees. Yet fewer than 1% of cloud customers change providers each year. The lock is no longer on the invoice — it sits in five dependencies nothing measures.

Airtable extensions are often reduced to charts sitting next to the grid. Yet the SDK documentation describes something else entirely: a full React application, hosted by the platform, with inherited permissions and reactive data. The architectural question — should an internal tool live inside the base or next to it? — is rarely asked seriously.

In late 2022, Gartner projected that 80% of low-code tool users would sit outside IT departments by 2026. Meanwhile, the average large enterprise hosts close to 80,000 applications built outside any software lifecycle, and 62% of the applications Zenity analyzed contain vulnerabilities. The question is no longer whether to allow citizen development: it is who governs what already exists.

Three ways to put a front end on an Airtable base, three cost models with nothing in common. Many teams choose by the screen, then discover the bill — in seats, in development, or in infrastructure.

The scenario that ran quietly at 50 executions a day starts losing events at 5,000, and the logs expired before anyone noticed. The real issue is not the choice of tool: it is the moment when five measurable criteria tip over.

Customer names retyped everywhere, totals maintained by hand, one tab per year: most no-code bases reproduce the flaws of the spreadsheets they replace. Normalization is taught in SQL, but it takes three habits to practice in an Airtable-style base — without writing a line of code.

Tools come and go; your data stays. Most SMEs pick the platform before thinking through their data model — and find out at migration time, when the export no longer means anything.