Building a modular software toolkit
How we translate linear effort into combinatorial value for customers at Airtable
Welcome to the inaugural post of the Airtable Engineering blog! We’re excited to have you here and to share some of the unique lessons we’ve learned from building Airtable.
At Airtable, we’re building a toolkit that anybody can use to build their own software. You can combine the many different building blocks provided in Airtable to create software that is truly tailored to your needs, rather than having to force your workflows into a one-size-fits-all solution that only vaguely applies to your problem.
Our toolkit-style approach brings significant benefits both for our customers and for our product development process, but it also carries some unique challenges that we’re looking forward to exploring through technical deep dives on this blog.
But first, let’s dig into how the Airtable thinks about the high-level benefits (and costs!) of creating truly modular software.
Modularity as a lever
By building a flexible and modular set of building blocks, we can develop features that are highly leveraged. When we add a new building block to the toolkit, it can interact with every other existing building block and thus unlock new permutations of how all the different pieces of Airtable can be combined together — often in ways we never even imagined. This means that linear effort on our part can yield combinatorial value for our customers.
For example, take rich text formatting. Airtable currently provides over two dozen field types, from basic ones like text, number, and single select fields, to more advanced ones like formula, linked record, and lookup fields. And recently, we added the option to include rich text formatting (bold, italics, checklists, etc.) in our long text field with a new WYSIWYG editor.
Because each new field type can be combined with all the other existing building blocks in Airtable, the introduction of rich text formatting unlocked not just a single use case but a whole suite of new use cases across different product surface areas. For example, without the need to additionally implement support for each of these individual use cases, it’s now possible to collect formatted text in Airtable forms, display rich text in page designer reports, and send emails with rich formatting through automations, to name a few.
This modular approach also leaves room for emergent behaviors. Our customers never cease to amaze us by finding new ways to combine different features in Airtable that we never ourselves imagined.
Modularity’s costs
On the flip side, the high modularity of Airtable presents a set of unique challenges in our product development process. Unlike in typical CRUD apps, where features are more self-contained, almost every feature in Airtable interacts directly or indirectly with many other features.
This means that each feature in Airtable is akin to a public API that other features can depend on. As we design new features or improve existing ones, we must think very critically about the interface that each feature exposes, and carefully consider backwards compatibility to ensure that we don’t accidentally break any dependent features.
The potential interactions between seemingly unrelated features can often lead to some interesting product design and engineering problems. One recent example is the interaction between automations and time-based formula functions (such as NOW()) — two features that might appear quite orthogonal on the surface. However, we realized that these features can be combined together to power creative use cases like sending automated reminder emails on a project due date, by connecting the “When a record matches conditions” trigger to a formula field. But as it turned out, making this interaction “just work” was a very tricky engineering challenge, one which we’re looking forward to exploring in more detail in a future post.
Another example is when our features interact in a way such that a seemingly minor bug can have significant privacy and security implications. For instance, let’s say a formula function has a bug that causes it to show the wrong answer under a very uncommon set of circumstances. Fixing the bug itself might be trivial, but doing so could have significant downstream effects. A customer may have used this faulty formula function in a field, then filtered a view based on that field, and finally publicly shared that view via a link. Now, if we simply fixed the bug without giving thought to these other potential interactions, we might inadvertently expose new records that were never intended to be shared.
Addressing these challenges at Airtable
So how do we mitigate the risks of our modular approach and lean into the combinatorial value it can create? In our experience, the most effective way is through thoughtfully crafted abstractions and interface boundaries, both in the product design and in the codebase. The product and technical architecture of field types, views, apps, and automations are some key examples of how we’ve applied these principles. We’re excited to share more about our thought process and some particularly interesting problems we’ve tackled in upcoming posts!
