How We Built a 49-Base Airtable Platform from Scratch

Hermon is a coaching platform based in the Netherlands that connects hundreds of coaches with clients across the country. When they approached us, they had outgrown their existing tools. Client data lived in spreadsheets, coach management was done manually, support requests fell through the cracks, and business reporting required someone spending a full day pulling numbers from different sources.

They needed a platform. Not software in the traditional sense -- they did not need a custom-built application with a six-month development timeline and a dedicated engineering team to maintain it. They needed a structured, relational, automated system that their operations team could actually work in day to day.

We built it on Airtable. 49 interconnected bases. 630 hours of design and build work. Here is how.

Why Airtable Was the Right Choice

This is a question we always address upfront, because Airtable is not the right tool for everything. For Hermon, it was the right tool for very specific reasons.

Relational data without a database team. Hermon's data is inherently relational. Coaches have certifications. Clients have coaches. Sessions link to clients and coaches. Invoices link to sessions. Support tickets link to clients. You need a relational model to make this work, but you do not need PostgreSQL. Airtable gives you linked records, lookups, and rollups -- relational database concepts in an interface that operations staff can understand and use.

Views and permissions. Hundreds of coaches need access to their own data -- their clients, their schedules, their records -- without seeing anyone else's. Airtable's view-based sharing and interface designer let us create controlled access points. Each coach sees exactly what they need. The operations team sees everything.

API-first architecture. Everything we built needed to connect to other systems. Airtable's API is well-documented and stable. Make.com has native Airtable modules. This means we can automate data movement between bases and between Airtable and external systems without building custom integrations.

Speed of iteration. A coaching business changes its processes regularly. New programs, new intake forms, new reporting requirements. In Airtable, adding a field, creating a new view, or adjusting an automation takes minutes. In a custom application, that same change goes through a development cycle.

The tradeoff is clear: you give up the performance and customization of a purpose-built application, and you gain speed, accessibility, and maintainability. For an operations platform serving a coaching business, that tradeoff is right.

The Architecture: 49 Bases, Explained

Forty-nine bases sounds like a lot. It is. Here is why we did not just build one big base.

Airtable has practical limits. Record counts per base, field counts per table, the number of linked record connections -- these all have ceilings. More importantly, a single base with dozens of tables becomes unwieldy. Different teams need different workspaces. Different data domains have different permission requirements.

We organized the 49 bases into major subsystems. Each subsystem is a group of related bases that handle one domain of the business.

Client Management (8 bases). The core of the platform. Client profiles, intake records, program enrollments, session histories, progress notes, and outcome tracking. These bases are the most heavily linked -- almost every other subsystem references client data.

Coach Management (6 bases). Coach profiles, certifications, availability schedules, performance metrics, and training records. The coach bases link to client bases through assignment records, creating the relationship map between who coaches whom.

Program Operations (7 bases). Each major coaching program has its own operational base with program-specific fields, workflows, and tracking. A shared program registry base links them all together and provides cross-program reporting.

Scheduling and Sessions (5 bases). Session scheduling, calendar management, attendance tracking, and session documentation. These bases integrate with external calendar systems through Make.com automations.

Financial Operations (6 bases). Invoicing, payment tracking, coach compensation, and financial reporting. These bases pull data from session records to generate accurate billing and connect to the accounting system.

Support and Communications (5 bases). Client support tickets, internal communications, coach support requests, and feedback collection. A ticketing system built entirely in Airtable with SLA tracking and escalation rules.

Business Intelligence (7 bases). Reporting dashboards, KPI tracking, trend analysis, and executive summaries. These bases aggregate data from across the platform using sync tables and scripting to produce the numbers that leadership needs for decisions.

Administration and Configuration (5 bases). System settings, user management, template libraries, and process documentation. These are the "meta" bases that configure how the rest of the platform behaves.

How 49 Bases Connect

The biggest technical challenge was not building any single base. It was making 49 bases work as one coherent system.

Airtable Sync. Airtable's sync feature lets you create read-only copies of tables from one base in another. We use this extensively. The client master record lives in the Client Management subsystem, but a synced version exists in Scheduling, Financial Operations, and Support. When the master record updates, the synced copies update automatically.

Make.com as the glue. For data that needs to flow between bases with transformation, validation, or conditional logic, we use Make.com scenarios. A new client intake triggers a Make.com scenario that creates records in the appropriate bases, sets up the coach assignment, creates the initial scheduling template, and generates the first invoice draft. One event, six bases updated, all automated.

Consistent key fields. Every base uses the same client ID format, the same coach ID format, the same date conventions. This sounds obvious, but it is the foundation that makes cross-base operations reliable. When a Make.com scenario looks up a client across three bases, it uses the same identifier everywhere.

Hub-and-spoke data model. The Client Management and Coach Management bases are the hubs. Everything else is a spoke. Data radiates outward from the central records. This means there is always a single source of truth for core entities, even though that data appears in dozens of places.

Handling Permissions for Hundreds of Coaches

This was one of the hardest problems. Hundreds of coaches, each needing access to their own clients, their own schedules, their own records. No coach should see another coach's data. The operations team needs to see everything.

Airtable Interfaces. We built custom interfaces using Airtable's Interface Designer for different user roles. Coach interfaces show only data filtered to their assignments. Operations interfaces show aggregate views with full access. Leadership interfaces show high-level dashboards and reporting.

View-based sharing. For bases where coaches need direct table access (rare, but sometimes necessary for data entry), we use shared views filtered by the coach's identity. Each coach gets a personal link that shows only their records.

Automation-gated access. Some actions should only be available to certain roles. A coach can submit a session note, but only an operations manager can approve it and trigger the billing process. We built these gates using Airtable automations that check the submitter's role before executing the next step.

The permission model is not as granular as a purpose-built application with row-level security. That is a real limitation. But for the coaching use case, the combination of interfaces, filtered views, and automation-gated actions provides the right level of access control.

The Automation Layer

The 49 bases are the structure. The automations are what make it a living system.

Airtable-native automations. Each base has its own internal automations for simple triggers: when a record is created, when a field changes, when a date arrives. These handle the in-base workflow -- status updates, notifications, field calculations.

Make.com scenarios for cross-base operations. Anything that touches multiple bases runs through Make.com. Client onboarding touches eight bases. Session completion touches four. Coach assignment changes ripple across five. These multi-base operations are orchestrated as Make.com scenarios with error handling and retry logic.

Scheduled operations. Daily, weekly, and monthly automations handle recurring tasks. Daily: sync session data to billing, update availability calendars, check for upcoming certification expirations. Weekly: generate team performance reports, flag at-risk clients, compile support ticket summaries. Monthly: produce financial reports, update KPI dashboards, trigger coach review workflows.

Data validation automations. Before data moves between bases, automations validate it. Is the client ID valid? Does the coach have the right certification for this program? Is the session within the authorized date range? Catching bad data at the point of entry prevents cascade failures downstream.

Challenges and What We Learned

Sync table limitations. Airtable sync is powerful but has restrictions. Synced tables are read-only. They do not carry over all field types equally. And there are limits on how many sync connections a base can have. We hit these limits and had to design around them, sometimes using Make.com to move data where sync could not.

Performance at scale. Large Airtable bases with tens of thousands of records and complex formulas can slow down. We learned to be disciplined about formula complexity, to archive old records rather than letting tables grow indefinitely, and to use scripting for heavy calculations rather than formula fields that recalculate on every load.

Change management. Changing a field in a hub base can affect twenty downstream bases. We built a dependency map -- a document that shows which bases reference which fields -- so that before changing anything in a core base, we know exactly what will be affected. This saved us from breaking changes multiple times.

Training the team. A 49-base platform is only useful if the team knows how to use it. We built documentation, recorded walkthrough videos, and ran training sessions for the operations team and coaches. The goal was always to make the platform self-service for day-to-day operations, with Etherwise handling structural changes and automation updates.

Knowing when Airtable is not enough. For a few specific needs -- complex scheduling optimization, advanced reporting visualizations -- we connected external tools rather than trying to force Airtable into doing something it was not designed for. Airtable is the platform, but it does not have to be the only tool.

The Result

630 hours of design and build work. 49 interconnected bases. A coaching platform serving hundreds of coaches and their clients, running on a system that the operations team owns and operates daily.

What used to be a tangle of spreadsheets and manual processes is now a structured, automated platform. Client data flows from intake through program completion without manual handoffs. Coaches access their schedules and records through clean interfaces. The operations team manages exceptions instead of managing data entry. Leadership gets real-time visibility into business performance.

The platform has been running in production, handling the daily operations of a growing coaching business. When Hermon adds new programs or new coaches, the platform accommodates them without a rebuild.

This is what a well-designed Airtable platform can do. Not a spreadsheet on steroids, but an actual operational system built on relational data, automated workflows, and controlled access.

If you are running operations on disconnected spreadsheets and manual processes, you do not necessarily need custom software. You might need a platform built on the right foundation. Book a Free Discovery Call and let us look at what that could look like for your business.