Govern a Base Like an Internal Product

This article's thesis, refutable in one sentence: a base a team depends on deserves what an internal product gets — an owner, conventions, a review, a changelog. If yours has run for three years with none of this and no incident, you hold a counterexample. And you got lucky.

Almost all of our projects start in the same place (Ownward internal data, 2026):

• an Excel file updated by hand every Monday;
• a spreadsheet used as a database;
• dashboards sent as attachments.

Decisions rely on them every week — and nobody answers for them.

Research points the same way: a systematic review of 77 papers published in 2020 in Information Technology and Control identifies shadow IT's causes — filling gaps in official systems, slow IT response times — and its risks: inconsistent data, undocumented and unmaintained systems. The risk does not come from the technology, but from the absence of an owner and documentation.

And the phenomenon is scaling up: in late 2022, Gartner forecast 80% of low-code users outside formal IT departments by 2026, up from 60% in 2021. Banning is a losing game. Realistic no-code governance starts lower: giving every base that matters product status.

We have described elsewhere the governance program at the organization level. This article covers the level below: the practice on one base, which can be set up in a week without waiting for the program.

First artifact: a name. Not "the team", not "the person who built it and left": one person, written into the base description, who arbitrates field requests, approves structural changes, and keeps the changelog. Microsoft's documentation on Power Platform Centers of Excellence (updated May 2025) makes this an explicit recommendation: named owners, naming standards, least-privilege access, regular audits.

Goodwill already exists: in a 2021 Gartner survey of 2,820 business technologists, 76% said they take responsibility for the risk of what they build. What is missing is the frame that turns diffuse responsibility into an explicit role. Three lines, pasted into the base description:

Owner    : first.last — arbitrates structure & access
Deputy   : first.last
Review   : quarterly · changelog: _CHANGELOG table

Airtable's official documentation frames structure well: one base per workflow, views rather than a proliferation of tables, a primary field that is "informative, unique, and short". But — verified on August 12, 2026 — it publishes no naming convention for tables, fields, and views. That standard is left to the team. Which is an opportunity: write yours on one page. Ours is versioned and applied across 30+ projects delivered inside our clients' tools (Ownward internal data, 2026). The transposable principles:

Adopt these rules or your own. What matters: they are written, dated, and a newcomer can find any object in under a minute. A naming convention is to a base what the schema is to the project: the invisible deliverable that conditions the others.

Airtable's revision history is retained for 2 weeks on the free plan, 1 year on Team, 2 years on Business, 3 years on Enterprise Scale (verified August 12, 2026). That is a good safety net for data. Not for structure: the "why" behind a renamed field does not survive the plan's retention window.

Software engineering solved this long ago. Keep a Changelog fits in one sentence — "Changelogs are for humans, not machines" — and six categories: Added, Changed, Deprecated, Removed, Fixed, Security. Semantic Versioning adds the grammar: an incompatible change is major and gets announced beforehand. Transposed to a base: renaming a field referenced by an automation or a dashboard is a major change — it is announced, not discovered. Concretely, a _CHANGELOG table inside the base itself:

Date       · Version · Category   · Description
2026-08-03 · 2.4.0   · Added      · fx_Margin field on Contracts (finance request)
2026-07-01 · 2.3.0   · Deprecated · "Old pipeline" view — removal in Q4

Cost: one line per structural change. Value: the only history that depends on neither the plan nor the platform.

An internal product knows its operating limits; governing an Airtable base means knowing yours. As of August 12, 2026: 1,000 records per base on the free plan, 50,000 on Team, 125,000 on Business, attachments from 1 to 100 GB depending on the plan. These are not flaws, they are parameters. The product reflex: write them into the base's fact sheet along with current volume, to decide before being decided for — one of the principles of how we build. Since the centralized admin panel arrives with the Business plan, below it, visibility rests on the team's discipline.

A base governed this way can carry much more than records. At one client, the full configuration of a synchronization engine connecting six CRM/ERP systems lives in a base: adding a source means adding a mapping, not writing code (Ownward internal data, 2026). That level of trust is built with this article's four artifacts.

What doing nothing costs — In 2020, nearly 16,000 positive COVID cases vanished from England's contact tracing: the Excel files had hit their row limit; researchers estimated (2021) that at least 1,500 deaths are linked to it (EuSpRIG). In January 2024, one wrong date in a spreadsheet cost Norway's sovereign wealth fund about $92M. The common thread: critical artifacts nobody governed.

One hour per quarter: the owner, a key user, a technical eye if available. Each item produces at most one action, logged in the changelog.

This last item is the most important: a review can conclude that the base has outgrown its frame. A weekly dashboard maintained by hand every Monday became, at one of our clients, a full multi-tenant application (Ownward internal data, 2026). The normal trajectory of an artifact that matters.

This practice is only worth it for bases that matter. Applied to every ephemeral spreadsheet, it becomes bureaucracy and will be bypassed — triage is the first act of governance. It then rests on discipline: a changelog abandoned for three quarters lies by omission, and nothing enforces it natively. It does not replace the organization-level program: global permissions, compliance, and backups belong to another tier. Finally, the quotas and retention periods cited, verified on August 12, 2026, evolve; check them before any architecture decision.