Airtable Relational Schema Design

We need help rethinking and building a clean relational schema for an internal operating system in Airtable. The current base is already being used by the team, but it has grown organically. The structure is partially flat, some tables/views are actively used, while others are barely used. Right now, documents are more often feeding information into Airtable, although ideally Airtable should become the source of truth and generate the necessary operational artifacts. We do not just need help with forms or automations. This is primarily structural work: analyzing the current logic, designing a relational schema, creating a clean new base/instance, documenting the structure, and providing recommendations for migration to the new schema. Potentially, the scope may also include implementation. System Context There are two main areas: 1. Feedback System A system for collecting and processing signals from external advisors, focus groups, internal teams, and stakeholders. It should support: - signal log / signal registry; - advisor tracking; - feedback intake; - synthesis dashboard; - status / gates / recommendations; - close-the-loop logic. 2. Product Catalog The product catalog currently has around 400 records, approximately 100 of which are active/live. We need to better structure products, statuses, relationships, data sources, lifecycle/gate logic, and reporting. Current State: - Airtable already exists and is being used by the team. - Current data accuracy is approximately 80%. - The schema is mostly flat, not relational. - Only the first few tables/tabs are actively used. - Some validation gates, tasks/decisions, and dashboard views are currently barely used. - There is no PII. - Any work with the live base must be handled very carefully: no production changes without approval. - The ideal approach is to analyze the current structure and build a new clean base separately in a sandbox. What Needs to Be Done: Phase 1 — Audit & Architecture Recommendation - Review the current Airtable structure. - Identify which tables, fields, and views are actually needed, which are duplicated, and which can be consolidated or removed. - Propose a relational data model. - Describe the main entities, relationships, primary keys, linked records, and lookup/rollup logic. - Propose a clean schema for the project and the product catalog. - Identify which dashboards/interfaces are needed for different user groups. - Prepare a short architecture memo or schema map. Phase 2 — Build Clean Airtable Base - Create a new clean Airtable base/instance. - Configure tables, fields, linked records, views, and basic interfaces. - Set up basic dashboard/reporting logic. - Prepare a migration map showing how to move data from the old structure to the new one. - Document the structure so the team can maintain it after handoff. - If needed, propose an automation strategy, but without overcomplicating the system. Expected Deliverables - Airtable schema map. - New clean Airtable base. - Tables + relationships + key fields. - Views/interfaces for core users. - Migration recommendation. - Short documentation for the team. - Governance recommendations: who enters data, who approves changes, which fields are required, and how to avoid duplication. - One short handoff call or Loom walkthrough. Important Security / Access Rules - No PII. - No unsafe tokens or personal integrations. - No need to connect AI/MCP/ChatGPT to the live Airtable base. - If access to the existing base is needed, it should be read-only or handled through exports, screenshots, or a structural description. - Any records/changes should be made only in the new test/clean base, not in the live production base. Who We Are Looking For The ideal candidate has experience with: - Airtable base architecture; - relational schema design; - Airtable interfaces, views, forms, and automations; - migration/cleanup of messy Airtable bases; - product operations / CRM / workflow systems; - documentation and handoff. In Your Proposal, Please Include - Examples of Airtable bases or systems you have built. - Whether you have experience converting a flat Airtable structure into a relational schema. - How you would approach audit → schema design → build. - Estimated hours for Phase 1. - Your hourly rate or fixed-price proposal for the first phase. - Whether you are comfortable working under NDA. Work Format We would like to start as soon as possible. The first step can be a small paid discovery/audit, followed by the full build if the architecture direction is clear.