Airtable’s Sale Changes Its Owner, Not Its Product Yet
Bending Spoons has agreed to buy Airtable, but the companies remain independent and have announced no immediate changes for users.
Bending Spoons has agreed to acquire Airtable in an all-cash transaction valuing the software company at $1.285 billion before its cash balance is included. The agreement was announced on August 4 and is expected to close later in 2026, subject to regulatory approval and other conditions.
For Airtable users, the most important word is “agreed.” The transaction has not closed. Bending Spoons and Airtable say they will continue operating independently until it does. Neither company announced an immediate pricing change, migration requirement, feature retirement or new contract policy.
That makes this a signal to review dependencies, not a reason to move a working system overnight.
Airtable combines a spreadsheet-like interface with a relational database, which links records across tables. Teams use it for product roadmaps, editorial calendars, customer operations, inventories and internal applications. The company says more than 500,000 organizations use the platform, including 80 percent of the Fortune 100.
These are not always casual documents. A base can sit at the center of forms, automations, API connections and reporting dashboards. Replacing the visible table may be easy. Rebuilding everything attached to it is the expensive part.
Bending Spoons says Airtable reached approximately $480 million in annual recurring revenue as of June 2026, up more than 20 percent from a year earlier. The buyer promised long-term investment and said it would build on Airtable’s role as a flexible workspace. Airtable described the deal as support for its effort to become an AI-native application platform.
Those are intentions, not a published product plan. The announcement does not specify which features will receive investment, how plans may evolve or whether staffing will change after closing.
The useful response is a lightweight continuity check. Identify which Airtable bases support critical work and assign an internal owner to each one. Record the forms, scripts, extensions, automations and external services connected to them. Confirm where API keys and service accounts are managed. Test whether a recent export can be restored into a usable structure.
This work is valuable even if Airtable remains unchanged. Cloud software can alter limits, permissions and integrations without an acquisition. A clear map reduces the risk that an undocumented automation fails after its creator leaves or a billing administrator loses access.
The buyer’s own description of its operating model makes preparation sensible. Bending Spoons says its acquisitions can involve reorganizing teams, overhauling technology, redesigning interfaces and changing monetization. That does not prove any particular Airtable change is coming. It defines the range of areas customers should monitor after the transaction closes.
The practical milestones will be more informative than the purchase price. Watch for the confirmed closing date, updated terms, plan or usage-limit changes, notices about APIs and automations, and a concrete roadmap from Airtable. Until then, the product people use today is still operated by Airtable as an independent company.
The signal this morning is simple. Ownership may change later this year. Workflows do not need to change today, but teams should understand how much they depend on them.
Notion’s High-Contrast Mode Makes the Interface Clearer, Not Every Page
The new display setting improves text, icons and borders, but workspace authors still own the accessibility of their content.
Notion has added a high-contrast display mode for people who find its muted interface difficult to read. The setting increases the visual separation of text, icons and borders. It is available now in the desktop app and on the web.
That sounds like a small appearance option, and in operation it is. Open Settings, choose Preferences, then Appearance and select high contrast. It works alongside the existing light and dark themes rather than replacing them.
The useful part is precisely that simplicity. Notion pages can contain dense databases, pale dividers, secondary labels and controls that recede into the background. Increasing contrast can make those elements easier to locate without asking every workspace author to redesign a page.
There are two practical limits to know before treating it as a complete accessibility solution. The option is not available on mobile, and independent release tracking indicates that the preference is stored per device. Turning it on at work does not automatically carry the choice to another computer.
The setting also belongs to the viewer, not the workspace administrator or page owner. That is valuable because contrast needs vary, but it means a team cannot assume that enabling it once has improved a shared document for everyone. Each reader must choose the presentation on each supported device.
High contrast modifies Notion’s application interface. It makes the product’s own words, icons, outlines and navigation more distinct. That can help people with reduced contrast sensitivity, but it can also be useful on a dim display, an aging monitor or a laptop used in bright light.
The feature answers a long-running criticism of Notion’s visual style. Users have complained for years that gray text, faint borders and desaturated colors can be difficult to distinguish, especially in dark mode. A 2024 accessibility assessment by design students at Pratt Institute also identified limited contrast control as one of several barriers in the product.
Notion now acknowledges the tradeoff directly. In announcing the mode, the company said its muted design can make content hard to read. Giving the reader a preference is better than assuming one level of subtlety suits every set of eyes.
It is still important not to call the feature proof of compliance with the Web Content Accessibility Guidelines, or WCAG. Notion has not published measured contrast ratios for the new theme. The W3C standard generally calls for a ratio of at least 4.5 to 1 between normal text and its background, with 3 to 1 permitted for large text. Visual information needed to identify controls and meaningful graphics should generally reach 3 to 1 against adjacent colors.
Those are testable thresholds, not synonyms for a setting named “high contrast.” A product can offer a stronger theme while particular elements still miss a target.
The mode cannot repair everything inside a workspace. Authors choose colored text, callout backgrounds, status labels, images, charts and embedded material. If a project board communicates urgency only through red, yellow and green tags, stronger interface contrast does not give those colors a second meaning. A person who cannot reliably distinguish them may still lose the message.
The same applies to screenshots containing tiny text and to diagrams whose lines differ only by color. High contrast around the image does not alter the image itself. Page creators should add clear labels, useful alternative text and written summaries where visual material carries important information.
Keyboard navigation, screen-reader behavior and focus order are separate concerns as well. The Pratt assessment found interaction problems that changing colors alone would not address. This release should be judged as one targeted improvement, not a replacement for broader accessibility work.
For teams, the sensible approach is to make people aware of the new option while continuing to design shared pages for ordinary viewing conditions. Do not require colleagues to discover a personal setting before they can read a status, find a control or interpret a dashboard. WebAIM notes that some people with low vision use operating-system or browser contrast overrides, but content authors still need to provide sufficient contrast in the default experience.
As a product decision, Notion’s new mode is refreshingly narrow. It does not promise to redesign work with AI or automate another routine. It gives readers more control over a visual system that the company admits can be too quiet. The next meaningful steps would be mobile support, preference syncing and published testing that shows which elements meet recognized contrast targets.
Until then, the feature is worth enabling for anyone who squints at Notion’s gray details. It makes the interface clearer. It does not remove the responsibility to make the information inside it understandable.
GitHub Makes Stacked Pull Requests a Native Workflow
The new public preview turns large code changes into smaller reviews without hiding their dependencies.
Large software changes create an awkward choice. A developer can open one enormous pull request that is difficult to review, or split the work across several branches and accept the job of keeping them synchronized.
GitHub is now trying to remove that trade-off. On July 30, the company placed stacked pull requests in public preview. The feature lets developers arrange a sequence of related pull requests as layers of one larger change. Each layer can be reviewed on its own, while GitHub keeps its position in the sequence visible.
This is not a new programming technique. Tools such as Graphite and Sapling have supported versions of stacked development for years. What is new is that the workflow now lives inside GitHub’s standard pull request interface and works with its existing reviews, automated checks and branch protection rules.
A pull request normally proposes moving changes from one branch into another. In a stack, the first branch targets the project’s main branch. The second targets the first, the third targets the second, and so on. Together they form an ordered chain.
Suppose a team is rebuilding a checkout page. The first pull request could reorganize shared data types. A second could replace the payment form. A third could add analytics. Reviewers can inspect those changes in focused pieces, even though the later work depends on the earlier layers.
GitHub adds a stack map to each pull request so reviewers can see what sits above and below the current layer. Crucially, the displayed difference is limited to that layer. Reviewers do not need to sift through the full accumulated change every time.
Developers can create stacks on GitHub’s website or use the new gh-stack command-line extension. GitHub also says the workflow is available through its mobile app and can be driven by coding agents. In the GitHub Copilot desktop app, one agent session can build on another and produce a corresponding series of pull requests.
Merging is where native support matters most. A team can merge the top ready layer together with every approved layer below it. It can also merge only the lower part of a stack. GitHub then rebases and retargets the remaining pull requests automatically, reducing the manual branch repair that often makes stacked work tedious.
The immediate audience is software teams handling migrations, broad product features and other changes that cannot sensibly fit into one small commit. The timing also reflects a newer problem. Coding agents can produce changes faster than people can understand them.
That does not make review optional. Generated code still has to fit the architecture, pass tests and behave correctly in production. If faster generation simply creates larger pull requests, the bottleneck moves from writing code to evaluating it.
Stacks offer a practical response because they constrain the unit of review. A database change can be discussed separately from the interface that depends on it. Security-sensitive logic can receive specialist attention without blocking review of unrelated presentation code. GitHub says early users including teams working on Next.js and TED have used this structure to make larger projects easier to inspect.
The useful angle is not that stacks make code automatically safer. They make the dependency structure legible. That can improve review only when each layer has a clear purpose, a manageable size and tests that match its scope.
Stacked pull requests are still a public preview and are rolling out over several days. Support for GitHub’s merge queue is arriving progressively over the following weeks. Teams should not assume every repository has the complete workflow yet.
There are also organizational costs. A stack can become harder to follow if its lower layers keep changing or if reviewers approve later work before understanding an unstable foundation. Ten tiny pull requests are not necessarily clearer than three coherent ones. The tool manages branch relationships, not editorial judgment about where one change should end and the next should begin.
Teams adopting the preview should start with work that already has natural boundaries. Dependency upgrades, schema preparation, feature logic and interface changes often separate cleanly. Each layer should build and test independently where possible, and its description should explain both its own purpose and what depends on it.
GitHub’s native implementation lowers the operational cost of this practice. Its real value will depend on whether teams use that convenience to produce smaller explanations, not merely more pull requests.