Interface Designer, custom extension or external app: three economics

Every well-modeled Airtable base soon raises the same question: what interface do you give the people who use it? Three answers exist, and they differ less in how they look than in how they cost.

Our thesis: choosing between Airtable Interface Designer, a custom extension, and an external application is a cost/audience/complexity trade-off — not an aesthetic preference. Each option wins in its own use case; none wins everywhere.

The rest of this article unpacks each column, then brings them together in a decision tree. All prices were verified on August 12, 2026 on the official pages.

Interface Designer is available on every Airtable plan. You assemble business views without writing code — no-code front-end in the strict sense: an autonomous team ships an interface in hours (the timeline view and sharing an interface separately from the base remain paid-plan features).

The economics live elsewhere: Airtable is charged per seat. Read-only access is free; any edit permission is a billed seat.

An "included" interface used by 25 staff who enter data therefore means $500 to $1,125/month in seats — the mechanics we detail in seat pricing math.

For outside audiences, two mechanisms exist. Interfaces can be shared with "interface-only" collaborators who never see the underlying base (up to 5,000 per interface); public sharing of an interface page is read-only, on paid workspaces. And Portals, an add-on sold in seat packs: from $120/month for 15 seats on Team, one portal per base.

Interface Designer wins when the audience is internal, already seated, and the need is a clean business view shipped fast: the marginal cost of the front end is then zero.

Extensions — components that add visuals or features to a base — exist on all paid plans. The Blocks SDK, public on GitHub under Airtable's own license, lets you build them to measure: React functional components and hooks, Node.js 22+, a dedicated CLI.

block release                # private release to the base's collaborators
block add-remote             # declare an additional target base (beta)
block release --remote prod  # deploy across multiple bases

The economics: a privately released extension is available to the base's collaborators, with no review and no additional software license. Its cost is development — and development alone. Its audience is bounded to the seats you already pay for: nothing extra on the license bill, but no wider audience either.

It is the right tool when the audience already is the team. We built 17 custom extensions in production in one year, including a full CRM — Aircall telephony, templated emails, SMS and WhatsApp, interactive maps — directly inside the base (Ownward internal data, 2026). Adoption was immediate, for a simple reason: nobody left their working tool.

Two documented caveats: deploying one extension across multiple bases goes through the CLI's "remotes", still flagged as beta; and extensions require staying on a paid plan.

Airtable's web API is designed to integrate your data "with any external system": REST, JSON, personal access tokens or scoped OAuth. An external application talks to the base with a single token; its end users are not Airtable collaborators and cost no seats.

The economics flip: cost becomes fixed, decoupled from audience — whether the application serves 50 or 5,000 users. Order of magnitude, verified August 12, 2026:

The real line item is building a complete application: auth, permissions, deployment, maintenance.

One architectural constraint applies. The API is limited to 5 requests per second per base and 50 per token, with monthly quotas per plan — 100,000 calls on Team, unlimited on Business. Beyond a handful of concurrent users, the pattern to remember is the replica: the application reads a synchronized store, not the base directly. Our 8 production Next.js/Supabase/Vercel applications — portals, dashboards, multi-tenant SaaS — rely on a sync engine connecting six CRM/ERP systems to a single source of truth (Ownward internal data, 2026). That discipline is part of how we build.

The external application wins when the audience extends beyond the base's walls: customers, partners, multi-tenancy, domain-based visibility. Below that threshold, it is oversized.

What doing nothing costs — Serving 30 external users through Editor seats on Team is $600/month, $7,200/year, where Portals at $120/month for 15 seats or an external app on fixed infrastructure (~$45/month excluding development) answer differently. Conversely, building a full application for 5 internal users who already hold seats means paying for development and then maintenance, for a front end Interface Designer would have shipped in hours.

Five questions settle most cases — keeping in mind that the true cost of a SaaS subscription goes beyond the license.

When two rows diverge, audience wins: it is what flips the cost model, not the comfort of the screen.

The prices, quotas, and limits quoted are those verified on August 12, 2026; Airtable states it may change its rate limits, including per plan. The exact boundary of billed seats varies by plan — the safe formulation: read-only is free, editing is billed. The decision tree ignores governance, compliance, and in-house skills, any of which can overturn a purely economic trade-off. Our production figures describe our context, not a market average. Finally, the options are not mutually exclusive: many deployments combine two — interfaces for the team, an external app for customers.