Recommended Workflow

The pattern that works best for teams using Effortless Bases in production:

The setup

Maintain a single 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.

Whenever your Airtable schema changes, spin up a fresh development base from the current Airtable schema, verify it, then sync the changes into production. Throw the dev base away when you're done.

The workflow loop

Edit schema in Airtable
        ↓
Create a new dev base (Clone source Airtable base)
        ↓
Verify schema looks correct
        ↓
Use Sync to migrate changes → Production base
        ↓
Discard the dev base

1. Design in Airtable — add tables, rename fields, adjust relationships
2. Create a fresh dev base — from your production base, open New Development Base and set Clone Source to Clone source Airtable base. If your production base uses magic link auth, check Copy magic link configuration so the dev base mirrors the same auth setup.
3. Verify — connect to the new dev database and confirm the schema matches what you expect
4. Sync to production — from your production base's Sync tab, select the new dev base as source and apply
5. Discard — once the sync is applied and verified, the dev base has served its purpose and can be deleted

Why a fresh dev base every time

Creating a new dev base directly from Airtable guarantees the schema in your dev base exactly matches Airtable right now. There is no carry-over state.

Reusing a long-lived dev base is risky: rebuilding an existing base does not always cleanly drop every remnant of previous schema. Tables, columns, or constraints that were present in an earlier iteration of your Airtable schema can linger in a rebuilt base, causing Sync to propose changes that don't reflect what's actually in Airtable today.

A fresh dev base sidesteps that entirely — what you see is exactly what Airtable describes.

Why this works

• Airtable is your schema source of truth
• Each dev base is disposable and always reflects current Airtable schema
• Production data is never at risk because you never rebuild production
• Sync gives you a controlled, reviewable migration step

Setting it up

1. Create your production base and build it once from Airtable
2. Any time you change your Airtable schema, create a new dev base from Airtable (see Bases & Branches), verify, then sync to prod