Great article!
I heartily agree with your these points, and thought I’d add some of my thoughts.
A dev environment is essential. I like to give my dev bases a different color/shade from the production base so that it is easy to tell them apart. When switching between bases, it is easy to get confused when everything looks the same.
Unfortunately, when integrating with third party tools having a separate dev environment can be difficult, because you have to create all the integrations with both the dev environment and the production environment.
Naming conventions are also essential when a base has many tables and fields. I recommend naming all tables and fields carefully, not just calculated ones. The names of your tables and fields are an important part of your user interface and documentation.
If you create a readme, make sure that you maintain it. Don’t make it so detailed that it is a burden to maintain. Inaccurate documentation can be worse than no documentation at all! Also remember to distinguish “user” information from “developer” information. Users need to know far less information than a developer who needs to maintain the system.
The article lists two main limitation when deciding whether to use Airtable: record limits and REST API rate limits. Records limits are one of the first considerations when evaluating the suitability of Airtable for a situation. You may need more records than you thought if you need a junction table or if you need to convert a field into a linked record.
On the other hand, rate limits for the REST API are important if and only if you are using the REST API. If you are depending on the REST API with anything but a token number of users, you need a system that includes caching (such a Sync, Inc.)
One additional limitation is the fact that Airtable requires an active internet connection, and it has a limited feature set on mobile devices. Make sure that the Airtable features that you need are available in the environment that you will be using.
