Recommended Workflow
The pattern that works best for teams using Effortless Bases in production:
The two-base setup
Maintain two separate bases:
Production base — your live app database. Built once from Airtable to set up the initial schema, then never rebuilt. All app data lives here. Schema changes come in via Sync only.
Test base — a branch of your production base. Used for schema iteration. Can be rebuilt freely from Airtable whenever your schema changes. Data loss here is acceptable.
The workflow loop
Edit schema in Airtable
↓
Build test base
↓
Verify schema looks correct
↓
Use Sync to push changes → Production base
- Design in Airtable — add tables, rename fields, adjust relationships
- Build test base — click Build in your test base to apply the Airtable changes
- Verify — connect to the test database and confirm the schema is what you expect
- Sync to production — from your production base's Sync tab, select the test base as source and apply
Why this works
- Airtable is your schema source of truth
- The test base is your staging environment — rebuild as many times as you need
- Production data is never at risk because you never rebuild production
- Sync gives you a controlled, reviewable migration step
Setting it up
- Create your production base first and build it once from Airtable
- From your production base, create a branch — this becomes your test base
- Any time you change your Airtable schema, build the test base, verify, then sync to prod