Many VC platform teams run their platform on Airtable: linked tables for companies, people, requests, intros and events, with views for each teammate. It works well early. It breaks down when many people edit it and when it depends on manual data entry, so feed it from email and calendar automatically and keep a small set of editors.
Airtable comes up on a lot of my calls with platform teams, usually with a sigh. Somebody built a beautiful base two years ago, with a table for everything. Now half the records are stale, the person who built it has moved on, and the team is quietly back in a spreadsheet. I don't think that's Airtable's fault. It's what happens to any system that runs on people typing.
So this isn't an anti-Airtable post. It's a post about how to run a platform on it without ending up in that spot, and how to tell when it's time to move part of the work somewhere else.
Why Airtable is a good place to start
For a new platform team, Airtable makes a lot of sense. It's flexible, so you can change the shape of your data as you learn what you need. It's relational, so an intro can link to a company and a person instead of living as text in a cell. A non-engineer can build and change it. And views let each person see only what they work on.
Most platform teams don't know yet, in year one, which programs will stick. A tool that's cheap to reshape is the right call while you figure that out. The trouble comes later, and it almost always comes from the same two places: who types the data in, and how many people change the structure.
Design for capture, not typing
Here's the pattern I see over and over. The base launches with a rule: log every intro, every request, every office hours session within a day. It holds for a few weeks. Then a busy month hits, the logging slips, and the gaps land exactly where the most work happened. People who have to log things by hand forget, and no amount of reminding fixes that. The fix is in the design.
So before you add a table, ask where its records already exist:
| Record | Where it already lives | How to get it in without typing |
|---|---|---|
| Office hours | Calendar invites | A calendar integration creates the record |
| Events | The event tool's guest list and calendar | Sync attendees after the event |
| Founder requests | Slack, email, monthly updates | A Slack integration for a requests channel; email is harder |
| Intros | Double opt-in email threads | Needs email capture, which Airtable alone doesn't do |
| Outcomes | Replies weeks later, LinkedIn posts, news | A scheduled check-in plus a review step |
Airtable's own automations or a tool like Zapier can handle the calendar and Slack rows. Email is the hard part, and it's where most platform work happens. Be honest with yourself about that gap. A base fed by calendar and Slack is still much better than one fed by memory, but it'll miss the intros and asks that live in inboxes.
Two rules for the founder side. Don't send founders an Airtable form to report anything. You almost certainly have most of what you'd ask for already, in updates, decks and email, and a form tells them you didn't look. And don't share a founder-facing view and call it a resource hub. Founders don't log in to these. The post on whether VC platform teams need a founder portal goes into why.
Fewer editors, more viewers
The second way bases break is too many editors. Everyone adds a field they need once. Single-select options multiply ("Fintech", "FinTech", "fin tech"). Three people create the same company with slightly different names. Six months in, nobody trusts a filter, because the data underneath it is inconsistent.
The fix is ownership:
- One owner per table. That person approves new fields and select options for their table. Everyone else proposes changes.
- Edit rights where the work is. The talent lead edits the talent tables. Partners don't need edit access to anything.
- Partners get answers, not bases. Most partners won't open Airtable. Send them a weekly digest in Slack or email, built from a view, and they'll actually read it.
- A quarterly field cleanup. List every field and how many records have it filled. Delete the ones nobody uses. (Archive them first if someone panics.)
A good test: if a new teammate can't learn the base in an hour, it has too many fields.
Track provenance and time
A platform base drifts from the truth slowly. A company's headcount, stage or latest raise gets typed in once and never updated. Six months later a partner quotes it to an LP.
Add two fields to every table that holds facts: Source (a link to the email, deck, post or note the fact came from) and Last verified (a date). Then build a view of everything not verified in 90 days. Spot-check with the link instead of redoing the research.
Metrics are where bases strain first. A cell holds one value, so a number like ARR either gets overwritten each quarter, losing its history, or turns into a column per quarter that nobody maintains. If you want metrics over time in Airtable, use a separate table with one row per company, metric and period. Even then, getting the numbers in is the real work. Cura handles that part: it sends metric requests to portfolio companies, follows up automatically and extracts the numbers from replies and documents, each linked to its source. Its REST API lets you pull those metrics into your base or your own warehouse.
And whatever you build, keep the data yours. Export the base on a schedule. If you have a data warehouse, sync to it. You don't want your platform's history stuck in one tool.
When does a VC platform team outgrow Airtable?
When the base needs more upkeep than it gives back. The usual signs are duplicate companies, fields nobody fills, numbers nobody trusts, and people keeping side spreadsheets. If keeping it current takes hours of typing every week, or partners stop opening it, the problem is the input, and a bigger base won't fix that.
A quick diagnosis:
| Symptom | What it usually means | What to try first |
|---|---|---|
| Duplicate companies and people | Too many editors, no owner | Assign table owners, merge duplicates once |
| Most fields half empty | Fields added for one-off needs | Quarterly cleanup, cut hard |
| Teammates keep side spreadsheets | The base doesn't fit their work | Ask what they track and why, then add a view |
| Numbers nobody trusts | No source, no history | Add source and last-verified fields |
| Hours of logging each week | Manual input | Automate capture from calendar, Slack and email |
| Partners never open it | Wrong delivery | Send a digest where they already work |
If the first five fixes don't hold, move the heaviest data out. Many teams keep Airtable for programs (events, office hours, expert networks) and use a purpose-built system for portfolio data and metrics that captures from email automatically. The broader design question, what to capture and how to make it searchable, is in how a platform team turns interactions into intelligence.
How should you structure an Airtable base for portfolio support?
Make one table per kind of thing, all linked to a Companies table: People, Requests, Intros, Events and Outcomes. Use fixed single-select tags, add a source link and a last-verified date to every record, and give each teammate a filtered view. Keep editing rights with the people who own each table.
A starting layout:
- Companies. One row per portfolio company. Name, stage, sector, lead partner, status. Every other table links here.
- People. Founders, executives, experts, candidates. Linked to companies where relevant.
- Requests. What a founder asked for, date, topic tag, status and who resolved it.
- Intros. Company, person introduced, reason, date, and the outcome 30 days later.
- Events. Event, date, attendees linked to People, and follow-ups promised.
- Outcomes. What came of the work: a hire, a customer, a raise. Linked to the request or intro that led to it.
Then add the views people use every day: "Open requests by owner", "Intros awaiting an outcome check", "Not verified in 90 days" and "This quarter's outcomes" for the partner digest. That last view is your value-add log, and it's the one you'll be glad you kept when an LP asks what the platform team actually does.