Airtable's $1.285bn sale to Bending Spoons raises data-exit questions

Airtable acquired by Bending Spoons

On 4 August 2026, Airtable was acquired by Bending Spoons for $1.285 billion, according to a post on dev.to. The piece was written by the developer of a competing product, who discloses that conflict openly, and it makes no prediction about Airtable's future pricing. As the author notes, nobody currently writing about the deal knows what will happen to customers' bills. Instead, the post uses the acquisition to pose a broader question about hosted business tools: if the vendor holding your operational data turned hostile tomorrow, what would you actually do?

The acquirer's record

According to the post, Bending Spoons' past acquisitions followed a recognisable pattern. At Evernote, the company reportedly cut headcount from 341 people to roughly 60 within twelve months and pared back the free plan. WeTransfer saw staff reductions and tighter free-tier limits after its acquisition. The author also cites TechCrunch reporting that traced a similar cycle of cuts and tightened free offerings across five Bending Spoons purchases. These figures come from the dev.to post rather than from either company directly, and the source includes no detail on what Bending Spoons intends to do with Airtable specifically.

The exit problem for no-code platforms

The heart of the argument is continuity. Teams that build on Airtable and similar tools often store operational records — orders, inventory, HR workflows, customer pipelines — rather than simple documents. The post contends that, for most teams, the realistic contingency if a vendor raises prices, removes features or shuts down is a CSV export and not much else. Such exports typically strip out field types, relationships between tables, automations and permission settings. The data survives; the system built around it does not.

A competitor's bar for data ownership

The second half of the post pitches the author's own product, so it should be read with that in mind — but the standards it lays out are separable from the pitch. Genuine data ownership, the author argues, has to mean at minimum:

• The software keeps running without the vendor. Not a self-hosting tier negotiated through a sales call, but an install that works end to end, with a licence verified locally rather than phoning home, and data that stays readable and exportable even after the licence lapses.
• Telemetry is described accurately instead of hidden behind blanket "no tracking" claims, with analytics opt-in and crash reporting inert until explicitly enabled.
• Security claims are checkable rather than promised. The author ships test scripts alongside the product so customers can verify tenant isolation and row-level security against their own installation.

Why it matters

A deal like this is a stress test for data-ownership assurances, which the post argues are usually marketing language rather than engineering commitments. For teams running core processes on a no-code platform, the practical lessons are unglamorous but real: test your exports and know exactly what they lose in types, relations, automations and permissions; understand which integrations would break if terms changed; and treat vendor continuity promises as claims to verify rather than assurances to trust.

The post also raises an AI-era angle worth noting. Generating interfaces has become nearly free, eroding the advantage no-code tools held a few years ago, but the data layer underneath — permissions, tested backups, input validation, audit trails — still has to live somewhere. As agents increasingly read from and write to these systems, a change in a platform's terms or availability after a change of ownership affects not only human users but the automated workflows built on top of them.