When No-Code Meets the Enterprise Workflow
Airtable built its reputation as a database tool for non-technical teams – the kind of product that marketing departments and project managers adopted without waiting for IT approval. But with the rollout of Cobuilder, its AI-powered app-generation feature, Airtable is making a direct play for something it never previously chased: the internal tooling market that Retool has spent years building its identity around. Cobuilder lets users describe what they want in plain language and watch a functional application take shape around their existing Airtable data – no drag-and-drop required, no component libraries to wrestle with.
The timing is deliberate. Retool has dominated the internal tools space by giving developers a visual environment to build admin panels, dashboards, and operational apps against live databases and APIs. It is fast, flexible, and loved by engineering teams at mid-size and enterprise companies. But it still requires someone who understands database queries, API authentication, and JavaScript logic to get full value out of it. Cobuilder, at least in its current pitch, does not ask for that person at all.
What Cobuilder Actually Does
Cobuilder is not a chatbot bolted onto a spreadsheet. It reads the structure of a user’s existing Airtable base – the fields, relationships, and record types already present – and generates a working interface on top of it. A logistics team that built their shipment tracking in Airtable can describe wanting a driver-facing portal or a dispatch dashboard, and Cobuilder produces something usable within minutes. The output is not just a visual wrapper; it generates real Airtable interfaces tied to live data, with forms, filtered views, and role-based access built in.
That is a meaningfully different value proposition from what Retool offers. Retool starts from scratch: you bring your database credentials, your API endpoints, and your logic, and the tool helps you build. Airtable Cobuilder starts from the data you already have inside Airtable and generates the app layer around it. For teams already living in Airtable – and there are many of them across operations, HR, sales, and support – that represents a dramatically shorter path to a working internal tool. The friction gap between “we have this data” and “we have a tool our team can use” collapses significantly.
Why Retool’s Moat Is Narrower Than It Looks
Retool’s advantage has always been its flexibility. It connects to anything – PostgreSQL, Salesforce, REST APIs, GraphQL endpoints, Firebase – and gives developers the control to build exactly what they want. That depth is real, and it is why engineering-led organizations have preferred it for internal tooling. But flexibility is only an advantage when the person using the tool needs flexibility. A surprisingly large share of internal tools are not particularly complex: an approval queue, a customer lookup panel, an inventory management interface, a form that writes to a database. These tools get built in Retool because Retool was the best option available, not because they required Retool’s full power.
Airtable is betting that the majority of those use cases live close enough to its existing product surface that Cobuilder can serve them. It is probably right about a meaningful portion of them. A support team running escalation tracking in Airtable does not need a developer to build them an admin panel in Retool – if Cobuilder can produce that panel in minutes from the data they already have, Retool never enters the conversation.
The more pointed threat is to Retool’s mid-market pipeline. Enterprise accounts with complex data infrastructure and dedicated engineering resources are not going anywhere; they have needs that require Retool’s connector depth and customization options. But the mid-market customer – the 50-to-500 person company where one or two developers are responsible for all internal tooling, and where every tool request involves a backlog and a negotiation – is exactly the customer Cobuilder is designed to absorb. Those teams often already use Airtable for something. Cobuilder gives them a reason to stop looking elsewhere.
Retool has not been standing still. The company has added AI-assisted development features, expanded its mobile app builder, and pushed deeper into enterprise workflows. But its product identity remains rooted in developer empowerment rather than business-user accessibility. That positioning made Retool successful. It is also the positioning that Airtable’s current push is designed to route around.
The Data Lock-In Question
One thing worth watching is what happens to teams that build mission-critical processes inside Airtable using Cobuilder. Airtable’s data model, while flexible, is not a traditional relational database. It has row limits, API rate constraints, and a pricing structure that scales with usage in ways that can surprise growing organizations. Companies that consolidate both their data storage and their internal tooling inside Airtable are making a meaningful platform bet – one that becomes harder to unwind as more workflows depend on the same underlying base.
This is not a hypothetical concern. It is the same tension that played out in the no-code automation market when companies built complex Zapier workflows and later discovered the per-task pricing made them unviable at scale. Airtable’s Cobuilder is compelling product storytelling, but the total cost of ownership math gets complicated when a company’s internal tools are generating thousands of Airtable record reads per day.
Where This Leaves the Internal Tools Market
The internal tools space is not a single buyer profile, and Retool and Airtable are not actually competing for the exact same customer – yet. Right now, Cobuilder competes for customers who were considering Retool but find Airtable’s integrated approach more appealing given their existing data infrastructure. That is a competitive threat at the consideration stage, not a direct replacement at the deployment stage.
But product categories do not stay neatly segmented when AI-generated interfaces close the complexity gap. The more capable Cobuilder becomes – the more API types it can reference, the more logic it can embed, the more conditional workflows it can generate – the more it encroaches on use cases that currently require Retool. Each release that expands Cobuilder’s output fidelity is another class of internal tools that no longer requires a developer or a separate tool platform. This is the same pattern playing out across several adjacent markets, including Hex’s push into Databricks’ analyst base, where a more accessible surface is gradually absorbing workflows that once required heavier infrastructure.
For now, Retool’s developer-first positioning protects its existing install base. But its ability to attract new customers who are evaluating internal tooling options for the first time – and who already have data sitting in Airtable – is getting squeezed in ways that will show up in its pipeline before they show up in its revenue numbers.
