Hi everyone, we’re trying to hire someone to level up our Airtable + Stacker setup and would love advice from people here who’ve scaled this kind of stack. Our setup today: • multiple Airtable bases • 500k+ records • frequent archival work • ~50 daily users • integrations with Stacker, Zapier, Make, n8n, Supabase, and Polytomic At this point, our challenge is less about building fast and more about building a solid architecture that scales and stays maintainable. We’re debating between profiles like: • low-code builders • backend/systems-minded engineers • implementation consultants For those who’ve seen this done well, what type of person would you hire? What titles/backgrounds tend to work best? And what mistakes should we avoid?

We don't have exactly the same setup as you, but we have 30+ Airtable bases and over a million records. We integrate Stacker/Zapier/Make, but don't deal with n8n, Supabase, or Polytomic. If I were to hire another person for this role, I would be specifically looking for somebody with a background in business analytics and at least a small amount of development experience. At this level, you are going to run into some custom coding, whether it is Airtable scripts, custom integrations, etc. You want someone with a developer mindset, but by far the biggest thing for us is data governance. You need somebody that can keep and maintain governance for your data structures and enforce SOPs for making changes to data structure. With the experience you guys have, it's probably less about "what can we build?" and more about "how do we build it?". Someone who has a background in business analytics, especially on the data side, is going to be able to think about business impact and needs, and structure data to suit the business the best. Also, just a word of advice: Airtable does not scale long term. We are on Airtable Enterprise due to the number of records that we have, and the API limitations are what's killing us now. When you start integrating and syncing data with multiple sources, it starts to become resource intensive on the database side, and the Airtable API limits cannot keep up. Unless the number of data transactions you run is really small and will stay there, you probably should be thinking about what can be done to move to a more scalable database. Supabase is great from all that I've heard. The real bummer is you lose Stacker along with that, unless they plan on adding an integration at some point in the future.

Thanks a lot Jeff — really appreciate you taking the time to share this, super helpful. The point on data governance really resonates — we’re clearly feeling that shift from “what can we build?” to “how do we build it right,” and your take on needing a strong analytics/data mindset makes a lot of sense. Also +1 on the Airtable API limits — we’re starting to hit similar constraints on our side with the growing number of integrations and data flows. We’ve begun experimenting with Supabase for a few smaller use cases, but still very early. Curious — have you looked into moving part (or all) of your database away from Airtable, whether to Supabase or something else? And if so, what kind of profile would you expect to lead that kind of transition? More of a data engineer, backend engineer, or something else?

> We’ve begun experimenting with Supabase for a few smaller use cases, but still very early. Curious — have you looked into moving part (or all) of your database away from Airtable, whether to Supabase or something else? > And if so, what kind of profile would you expect to lead that kind of transition? More of a data engineer, backend engineer, or something else? In our case, we are using Google Firestore as our database. The disadvantage with moving away from Airtable is that when you start using other databases, you can no longer use Stacker as the front end, so you need to find a different frontend technology. We've been developing our own custom web apps using Flutter (long story behind the reasoning but you can use any stack). We ended up building a two-way sync between Airtable and Firestore in order to use Airtable as the source of truth but have more scalable data access in Firestore. As we continue to build more full-stack apps, we will see a natural migration of data to Firestore, with Firestore becoming the ultimate source of truth over time. Yes, there are no-code solutions out there that connect to Supabase or other similar backends, and some of them are really good. But we ultimately decided that between recent advances in AI and the need for just a little bit more customizability, we would be better off with full stack apps in the long run. For us, I have personally been acting as data engineer, and I have two full-stack developers on my team, besides a full-time Airtable/Stacker developer. Long term, I will delegate the data engineering responsibilities to my current Stacker team, with them focusing on data architecture and integrations between all of our systems (Airtable, Stacker, Firestore, ecommerce, ERP, etc.). > On the Airtable side, the closest role we’ve found so far seems to be something like a Business Systems Analyst or Architect — does that match what you’ve seen work well, or would you frame it differently? That's a great question. This sounds perfect in my opinion. You're really going to need both. An architect is an essential role in governance, but he's not going to know what to do without being able to look at your business needs and actually come up with requirements for the data structures. If your team is big enough (10+ developers), you should probably consider two separate people doing this. But for a smaller team, one person can handle both responsibilities. A common job title for someone that does both is "Solutions Architect" or "Systems Architect".