A marketing system has to do a whole bunch of things: track work, hold context for AI tools, hold drafts, measure performance, keep track of relationships, and more—plus join it all together in some useful way without you doing it by hand every Monday morning.
I put nearly all of this into one Airtable base. Not because Airtable is the best database, and not because I love spreadsheets. It was because of what I could use to drive the database: AI tools like Claude that use the database better and far, far faster than I ever could myself.
A marketing OS is the single place your marketing thinks from: one store holding everything, structured tightly enough that software can read it and supporting time-saving workflows. Mine is an Airtable base with eight tables in it. Here's why I started there, its limitations, and when you should leave—because I've already moved on (kind of), and you should know when it's time for you to move on, too.
Some of you may use Notion instead of Airtable for this type of system, and all of the same applies.
What does a marketing OS actually have to do?
Did you ever sit down and think about how many different jobs your marketing system has to do? Here are the main ones.
- Track campaigns. What is running, what stage it is at, what is due.
- Hold the context that conditions the work. Briefs, audience profiles, voice profiles, positioning. The material that makes the difference between output and good output.
- Hold drafts. Or at least point at wherever they live.
- Measure. What went out, when, and what happened after.
- Remember people. Subscribers, buyers, prospects.
- Be a library for everything that doesn't have its own home yet, or that points to where things do live.
- Automate the joins between all of the above.
This is the scaffolding that allows you to create and deploy campaigns, run analyses, and build relationships.
Most tools do two or three of these well and make you bolt the rest together into a Frankensteined marketing "ecosystem." The data lives in different applications that may or may not talk to each other (or one gargantuan, complex, and frankly unusable platform). You end up with a project tracker that knows nothing about your audience, a doc folder your automation can't read, and a spreadsheet nobody opens.
The context that AI tools need to reason over and ground themselves against hallucination is buried in a dozen different apps—if it was ever explicitly spelled out—and often in a format that's unreadable to them. You need to make marketing context accessible to AI tools if you ever want them to produce something besides the slop everyone complains about.
Airtable is a simple solution that brings all of these functions together to make your data and workflows usable by you and the machines. Not perfectly. But in one place, with everything linked to everything else, which turns out to matter more than any single feature on the list.
The thing that actually decided it: Claude can drive it
Here's the part that set me down this path during the AI boom, and it's not a feature of Airtable at all.
I don't open Airtable to build in Airtable. I describe what I want to Claude, and Claude builds it. Airtable ships an MCP server—available on every plan, including the free one—which lets an AI assistant read your bases and write to them directly. Not copy and paste. Not an export. It reads your schema and edits your data. You literally don't even need to know how to use Airtable to operate it.
An example from the day I'm writing this: I needed a new content project set up—a project record, twelve article records under it, and two more records for the email and the social post that promote them, all linked to the right parent and carrying the right status. Nineteen records across five tables so I could track them.
I described the project in a few sentences. Claude read the base's schema first to find the field names and the existing options, then created the records in five batched calls, linked each one to its parent, and reported back what it had made. I didn't open the Airtable interface once.
The part I didn't expect is what that does to your learning curve. You're watching someone competent use the tool while narrating what they're doing. After my first few sessions of doing this, I knew what a linked record field was, why single select options matter, and how the API thinks about a table—not because I read the documentation, but because I watched the work happen and asked questions when something surprised me. I went from knowing nothing to being competent with Airtable in no time.
For me, it all started with one sentence in a connected Claude session:
Build me a base with tables for campaigns, content pieces, and audience profiles, linked appropriately.
It took a lot of building and iterations using the system in real marketing operations, but I essentially ended up with a working system before I had even learned the interface. That's the productivity jump, and it's larger than any single thing Airtable does on its own.
Seven reasons it was safe to bet on
The connector is why I chose Airtable. These are the reasons why I don't regret my choice.
Owned and durable.
- You can get your data out. Any grid view exports to CSV, on any plan. One table per file. That's not an exciting feature, but it's the one that lets you commit. The cost of being wrong is an afternoon of exports, not a hostage negotiation.
- It scales far past where you start. Not infinitely, and I'll come back to where the wall actually is. But a small marketing operation running for a year or two doesn't come close to the record ceiling. The thing that breaks first isn't row count.
- It's boring in the way infrastructure should be. In months of daily use I haven't lost data, and I haven't spent an afternoon on an outage. I can't give you an uptime figure and I'm not going to invent one. I can tell you I stopped thinking about it, which is the only review of a database that matters. And if I ever break something myself—delete a table, let an automation run wild—Airtable has been quietly snapshotting the base the whole time. Restoring a snapshot creates a fresh copy of the base as it was, so you can't make things worse trying to fix them.
It plays well with everything else.
- It connects to what you already run. My base talks to my email platform, my store, my automation layer, and my writing tools. When something doesn't have a native integration, there's an API and a large market of connectors that do.
- When you get stuck, the answer can be found. The documentation is genuinely good, and there's a large, active community—Airtable's own forums and the r/airtable subreddit—where almost any question you have has already been asked.
Cheap, simple, and shaped to your work.
- The free tier is enough to learn on, and the paid tier is cheap for what it replaces. I wouldn't call the free tier robust. I'd call it exactly enough to find out whether this works for you, which is all a free tier owes you. Free gives you 1,000 records per base, 1GB of attachments, two weeks of revision history, and 1,000 API calls a month, with no automations. Team is $20 per collaborator per month billed annually ($24 billed monthly) at the time of writing, and lifts those limits to 50,000 records, 20GB, a year of history, and 100,000 API calls. That's a low price that will support a lot of growth.
- You shape it to the work, not the other way around. Go back to the jobs a marketing OS needs to do. Each one is a table you define, with the fields you decide, in the views you need. When the way I plan campaigns changed, I reshaped the base in an afternoon. Software that makes you work its way instead of yours is software you'll quietly stop using.
Where does Airtable fall short?
For use with AI chatbots, Airtable is a great place to start—arguably the place to start—but it has some gaps you'll need to fill as you grow.
The connector runs on your schedule, not the base's. Claude can read your base and write to it, but only when a conversation asks it to: you, live, or a scheduled task you've set up in Claude to run every morning and, say, draft posts for whatever entered the Approved view overnight. What it can't do is respond to an event in the base the moment it happens. A form submission at 2 a.m., a status flip to Approved—Claude doesn't know until you or your schedule asks. If the base needs to react instantly—send the welcome email the second the form comes in—that's an Airtable automation (or Zapier or Make). Claude will help you build those. It just won't be the thing running them.
The free tier's API cap is real, but the connector isn't what spends it. Airtable's docs say the MCP server runs on the public API and is subject to the same rate limits—the per-second throttle. They don't say it draws down the monthly allowance, and after months of heavy use through Claude, my workspace's Usage tab still shows zero of the free plan's 1,000 calls used. What does spend that allowance is anything you wire up yourself: Zapier, Make, Softr, a script of your own against the REST API, or Claude running your code through the API rather than the connector. If you're building integrations on the free plan, that's the ceiling you'll hit first, and it's a cheap one to lift.
Long prose in a cell is miserable. This is the one that actually forced a change in how I work. A campaign brief is eight hundred words of argument. In a database cell it's a cramped box you scroll inside, with no outline, no links to anything, and version history measured in weeks. Writing in it feels like writing on a napkin. This isn't Airtable being bad at its job; it's a database being asked to be a document.
It's not a CMS and it's not an email tool. It points at them. That's the right design, and it's also the honest edge of "everything in one place"—the record is in one place, the published page and the sent campaign are somewhere else.
What about Notion, or just markdown files?
Two fair alternatives, and I've used both. In fact, plain markdown files are now the foundation of my marketing operations.
Notion is the better choice if what you actually want is a wiki. Pages nest, documents read beautifully, and writing long prose in it is a pleasure in exactly the way writing long prose in Airtable is not. It also has databases. They're simply thinner: fewer view types, weaker filtering, and an automation layer that's a generation behind. If your system is mostly documents with a little structure, use Notion. If it's mostly structure with some documents, the trade runs the other way. I ran my narrative work in Notion for a while and moved it out, not because Notion was bad but because the structured half was where the leverage was when using AI tools.
Plain markdown files are more powerful and more scalable than either. Text files you own outright, that live on your disk, that every tool ever written can read, that version in git, that an AI tool can read and edit natively. For SMBs, there's effectively no ceiling.
But there are some downsides that make markdown not necessarily the place to start. A markdown system grows large and complex fast, and the complexity is yours to manage. There's no native interface—you add one with an app like Obsidian if you want it, and you build the conventions, the folder structure, and the queries yourself. The learning curve is meaningfully steeper. As your knowledge base grows, your AI tools take longer to crunch through the analysis and synthesis (even though markdown is the format they handle most efficiently) and you may spend a lot more time making decisions.
Basically, you can create amazing things, but don't shift to markdown unless you're prepared to invest a lot of time into building—at least up front.
And some jobs a database just does better: give me a filtered, sorted, grouped view of forty campaign records by status, and I'll take Airtable over any query I could write against a folder of files.
If you're small and short on time for managing systems, Airtable keeps it lean. That's not a consolation prize. It's the correct answer for most people for a long time.
So when do you leave?
You don't, exactly. Here's what actually happened to me.
For months, my campaign briefs lived in a long-text field in the base, along with everything else. It was fine—great even, since giving up reading text in a polished Word doc was a small sacrifice for multiplied productivity. I'd built a sleek content marketing system that made me a one-person marketing machine. But, human as I am, I craved more.
So, since running the system via Claude connectors was my biggest point of leverage, I shifted the bulk of my system to plain markdown files that Claude could query more efficiently. That left the Airtable base holding the status, the dates, the links between records, and a pointer to the relevant markdown files. Two stores now, not one, each doing what it's best at. Still vastly simpler than the cobbled-together ecosystem of third-party apps it largely replaced.
The rule that decided what moved is the most useful thing in this article, and it's one question:
Would you rather read it or query it?
Read it and/or query it, and it belongs in a markdown file. The brief, the positioning, the reasoning behind a decision, anything a person sits down with. Query it alone, and it probably belongs in the base. Status, dates, owners, relationships, anything you want to filter, sort, or count.
Apply that test to the various jobs of a marketing OS and the split reveals itself. Tracking, measuring, remembering people, automating the joins: those are queries, and they stay in Airtable with no problem. The context that conditions the work, and the drafts themselves: those are reading, and they moved to files.
Which is why starting in Airtable costs you nothing later. You're not building something you'll throw away. You're building the half that stays, and discovering the other half by feel—when a cell starts to feel like a napkin, that's the system telling you which half you're in.
Start there. You'll know when.
I write about running a full marketing operation alone with AI infrastructure doing the work a team would otherwise do. If you operate solo or with a small team, my newsletter will help you scale quality and reach while remaining lean.
