101 USD
12 proposals
Need help rethinking and building a clean relational schema for an internal operational system on Airtable.
The current database is already in use by the team, but it has grown organically: the structure is partially flat, some tables/views are actively used, while others are hardly used, and documents currently rather "pull" information into Airtable, although ideally Airtable should become the source of truth and generate the necessary operational artifacts.
What is needed is not just help with forms or automations, but structural work: analyzing the current logic, designing a relational schema, creating a clean new database/instance, documentation, and recommendations for migrating to the new schema.
And potentially even implementation.
System context:
There are two main directions: Feedback system
A system for collecting and processing signals from external advisors, focus groups, internal teams, and stakeholders. It should support: signal log; advisor tracking; feedback intake; synthesis dashboard; status/gates/recommendations; close-the-loop logic. Product catalog
The product catalog currently has about 400 entries, approximately 100 of which are active/live. It is necessary to better structure products, statuses, relationships, data sources, lifecycle/gate logic, and reporting. Current state: Airtable already exists and is used by the team. The current data accuracy is about 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 hardly used. There is no PII. Any work with the live base must be done with maximum caution: no changes in production without agreement. The ideal approach is to analyze the structure and build a new clean base separately in Sandbox. What needs to be done:
Phase 1 — Audit & architecture recommendation Look at the current structure of Airtable. Determine which tables/fields/views are actually needed, which are duplicated, which can be merged or removed. Propose a relational data model. Describe the main entities, relationships, primary keys, linked records, lookup/rollup logic. Propose a clean schema for the Project + Product catalog. Determine which dashboards/interfaces are needed for different users. Prepare a short architecture memo or schema map. Phase 2 — Build clean Airtable base Create a new clean Airtable base/instance. Set up tables, fields, linked records, views, basic interfaces. Set up basic dashboard/reporting logic. Prepare a migration map: how to transfer data from the old structure to the new one. Document the structure so that the team can maintain it after handover. If necessary, propose an automation strategy, but without excessive complexity. Expected deliverables: Airtable schema map. A new clean Airtable base. Tables + relationships + key fields. Views/interfaces for main users. Migration recommendation. Short documentation for the team. Governance recommendations: who enters data, who approves changes, which fields are mandatory, how to avoid duplication. Optionally: 1 short handoff call / Loom walkthrough. Important security/access rules: No PII. No dangerous tokens or personal integrations. AI/MCP/ChatGPT/Claude cannot be connected to live Airtable. If access to the existing base is needed, it must be read-only or through export/screenshots/structural description. Any records/changes are made only in the new test/clean base, not in live production. Who I am looking for:
The ideal candidate has experience in: Airtable base architecture; relational schema design; Airtable interfaces, views, forms, automations; migration/cleanup of messy Airtable bases; product operations / CRM / workflow systems; documentation and handoff. In your response, please indicate: Examples of Airtable bases or systems you have built. Whether you have experience transforming a flat Airtable structure into a relational schema. How you would approach audit → schema design → build. An estimated number of hours for Phase 1. Your hourly rate or fixed-price proposal for the first phase. Whether you are willing to work under an NDA. Work format:
It is preferable to start as soon as possible. Initially, a small paid discovery/audit can be done, after which we can move to the full build.
