A relational database CRM with a schema that holds up.

With a proper relational schema, yes — for a while. Airtable has record and automation limits; the audit will flag if you're approaching a point where a dedicated CRM makes more sense.

Yes. Re-modelling the schema into proper linked tables, fixing rollups, and rebuilding interfaces on top is a common project.

Through Interface Designer, forms and shared views — so external or read-only users don't touch the underlying base or its linked-table structure.

A lookup pulls a value from a linked record; a rollup aggregates across multiple linked records with a formula. Getting this distinction right early avoids rebuilding fields later as the schema grows.

Day-to-day use through Interfaces, yes. Schema changes — new linked tables, altered rollups — usually still need someone who understands the relational structure, which we document at handover.

The first week is schema design — deciding which entities are genuinely separate linked tables; the middle of a 2–8 week project builds the tables, rollups, automations and Interface Designer layer; the final stretch is migration, permissions setup and user testing on the Interfaces rather than the raw grid.

Schema complexity — how many linked tables and rollups the data model actually needs — and whether a proper Interface Designer layer is required move the cost more than record count or seats, so we scope from the relational design, not a flat per-base fee.

A post-launch window to adjust automations and interfaces once real usage surfaces edge cases, plus documentation so someone on your team who understands the relational structure can maintain it. Retained support is available beyond that.

Through native integrations, Airtable's API, and Zapier or Make for lighter-weight connections — commonly wired to intake forms, email tools and other bases via sync tables, scoped against the plan's API and automation-run limits so the integration holds up at real usage.

When record volume, automation-run needs or the number of concurrent editors starts pushing against plan ceilings regularly rather than occasionally — a proper build should flag this trajectory during the project so it's a planned move, not a surprise wall.

For a simple, single-table tracker, sure. Where teams get into trouble is exactly the schema-design decisions this page describes — normalizing into linked tables, choosing lookups versus rollups correctly, and building an Interfaces layer so non-technical users never touch the raw grid. Those decisions are cheap to get right at the start and expensive to unwind after a year of real usage.

Usually worth fixing rather than discarding — most unmanageable bases have real, migratable data trapped in a poor structure. We audit the existing schema first and re-model it into proper linked tables, preserving the data rather than starting from a blank base.

Templates are a reasonable starting point for a generic use case, but they're built for nobody's specific process — a real CRM needs the schema, automations and Interfaces shaped around how your team actually tracks accounts, deals and delivery, which a template can't do out of the box.

Record limits per base scale by plan, and a CRM that logs every activity and email can reach them sooner than expected. They matter most for high-volume activity tables. We estimate growth during design and separate high-volume data into archivable tables or synced bases, so a plan ceiling becomes a planned upgrade.

On annual billing, Airtable's Team plan runs about $20 per seat per month and Business about $45, or roughly $24 and $54 billed monthly, with Enterprise Scale starting around $60 per seat and negotiated, per 2026 pricing guides. Because every editor is a paid seat, the total depends on how many people genuinely need write access.

Generally, paid seats apply to people who edit or create records inside the base, while people submitting through shared forms or viewing shared views typically don't need one. Rules and limits change, so we verify against Airtable's current plan documentation when scoping, and design interfaces to keep paid editor seats to the people who need them.

We first identify the entities hiding inside the sheet, such as companies, contacts, deals and products, then split them into linked tables and import each with a unique key. Repeated text values become linked records, and dates and amounts get proper field types, so the result is a relational base rather than a prettier grid.

For workflows that stay inside Airtable, often yes: record-triggered actions, notifications and field updates. For chains across many external apps, Zapier or Make can be more flexible. The deciding factor is run limits, since native automations count against your plan, so we estimate monthly volume before choosing where each workflow lives.

Yes — forms and Interfaces can be shared externally with the right permission settings, and sync tables let a client-facing view pull from the same underlying data without duplicating it. The scoping question is usually how much of the interaction needs to feel like a branded portal versus a functional form, since heavier portal needs sometimes point toward a dedicated tool layered on top.