In early March 2020, I joined a Slack channel with about thirty strangers. By the end of that week, we'd incorporated a nonprofit. By the end of the month, we'd onboarded 400 volunteers. By the end of the year, we'd shipped over 5 million units of PPE to frontline healthcare workers across the United States.
That organization was Project N95; the national clearinghouse for authentic, affordable N95 masks and other personal protective equipment. The New York Times wrote about us as a more reliable place to buy N95s than Amazon. The NIH partnered with us to distribute COVID-19 tests. We were written into CDC guidance documents.
My title was Chief of Staff. In practice, I ran our technology infrastructure. This is the story of what we built and what it taught me.
The Stack That Built Itself
When you're standing up a nonprofit in a week during a global pandemic, you don't have time for an architecture review. You grab whatever's free, whatever scales, and whatever your volunteers already know how to use.
For us, that was Airtable.
Airtable became everything. Candidate management for 400+ volunteer applications. Supplier vetting databases. PPE inventory tracking. Marketplace listings. Personnel files. Real-time dashboards for stakeholders. And — critically — the backend for our React storefront.
Airtable gave us their entire enterprise stack gratis, in-kind. Stacker layered user portals on top. Intercom handled customer communications were completely comp’d. Zapier and Workato automated the data movement between systems. Okta handled identity and SSO.
I wrote about the full tech partnerships in a Medium post back in 2020, and the Airtable candidate management system in 2024. But what I didn't write about — because I hadn't fully understood its significance yet — was the architectural pattern that emerged.
Airtable as Both Database and CMS
Our React storefront was built on Gatsby. It worked like this:
- Product data, supplier info, and marketplace listings lived in Airtable
- Gatsby queried Airtable at build time through GraphQL source plugins
- Fresh GraphQL fragments were generated for each nightly build based on the latest Airtable data
- React components consumed the GraphQL data
- The built site deployed as pure static HTML on Netlify
- Zero runtime connection to Airtable — the site was just HTML files
This meant Airtable was doing double duty. It was our operational database (volunteer management, supplier vetting, inventory tracking) AND our content backend (product listings, marketplace data, marketing content). Two completely different consumers reading from the same tables.
At the time I didn't think of this as unusual. We were in crisis mode. Whatever worked, worked. But looking back, this was the exact pattern I'd later build with Notion: one workspace serving multiple consumers through different access patterns.
The Contentful Detour
As the organization matured, we added Contentful as a dedicated CMS for richer marketing content and blog posts. Contentful was good at what it did — structured content, preview environments, localization support. But it was $300/month, and it meant I now had two content backends that Gatsby needed to source from at build time.
The complexity wasn't in the Gatsby build; Gatsby handles multi-source sourcing gracefully. The complexity was in the editorial workflow. "Where does this content live? Is it in Airtable or Contentful? If I update the product description, do I update it in Airtable (where the storefront reads it) or Contentful (where the marketing page reads it)?" Same content, two homes, constant drift risk.
This is the lesson that stuck: your CMS should be the tool you already live in. If your team lives in Airtable, make Airtable your CMS. If you live in Notion, make Notion your CMS. (I wrote about exactly how I do this in Building a Headless CMS with Notion + Gatsby.) Adding a dedicated CMS on top of your existing knowledge management tool creates exactly the kind of dual-source confusion that causes content drift.
What 400 Volunteers Teach You About Systems
Project N95 wasn't a normal engineering team. We had 400+ volunteers — lawyers, doctors, supply chain experts, engineers, students — distributed across every timezone, most of them donating 10-20 hours a week alongside their real jobs. The turnover was intense. People would be deeply engaged for three months and then disappear.
This meant every system had to survive being operated by someone who'd never seen it before. The Airtable views needed to be self-explanatory. The Stacker portals needed to guide people through workflows without training. The Slack channels needed to be organized well enough that a new volunteer could find what they needed without asking.
This is where I learned the principle I now apply to agent governance: systems that depend on the operator remembering the rules don't work at scale. At N95, we couldn't count on volunteers remembering which Airtable view to use for which workflow. We had to build the workflow into the view itself — filtered, sorted, with conditional formatting that made the next action obvious.
That's the same insight behind hook-based enforcement for AI agents. You can't count on 15 concurrent agents remembering the rules. You have to build the rules into the system itself.
The Architecture Lessons I Took Forward
Here's what Project N95 taught me that directly shaped what I build today:
1. Your operational tool IS your content tool. Stop paying for a separate CMS when your team already lives in something that has an API. At N95 it was Airtable. For me now it's Notion. The content is already there — just build a pipeline to serve it.
2. Static-first is the right default. Our Gatsby storefront had zero runtime costs, zero server vulnerabilities, and zero cold starts. It survived traffic spikes from NYT coverage without any scaling intervention because there was nothing to scale — it was just HTML files on a CDN. I still build this way.
3. Build-time data sourcing is underrated. Gatsby's sourceNodes pattern — query any backend at build time, transform into GraphQL, consume in React — is incredibly powerful and criminally underused. It works with Airtable, Notion, Contentful, local files, or anything with an API.
4. Dual-consumer databases are natural. Airtable serving both operational workflows AND a static site from the same tables felt weird at first. Now I have Notion serving both Gatsby builds AND AI agent context from the same databases. (The full governance architecture is in What I built to govern concurrent AI agents.) The pattern works because the consumers want different fields from the same records.
5. Systems that survive chaos are systems that don't depend on human memory. 400 rotating volunteers taught me this. 15 concurrent AI agents reinforced it. If your governance depends on the operator remembering the rules, you don't have governance.
From N95 to Today
Project N95 wound down operations in 2024 after fulfilling its mission — 43 million units of PPE to over 1.1 million people. The organization's about page says it beautifully: "With the right team, you can do amazing things."
The tech stack we built lives on in the architecture patterns I use every day. Notion as CMS mirrors Airtable as CMS. Gatsby as static renderer is unchanged. The "Publish To" relation in my Blog Posts DB works exactly like the category filtering we used to route Airtable data to different storefront sections. The principle that your operational tool should also be your content tool — that came straight from watching Airtable do both at N95.
And the newest evolution — Notion as context pipeline for AI agents — is just the dual-consumer pattern taken one step further. At N95, Airtable served volunteers and the website. At my current setup, Notion serves Gatsby and the agents. Same pattern, different consumers.
The pandemic taught me to build for chaos. The agents are a different kind of chaos. But the architecture survives both.
Previously: The Tech Companies Coming Together to Support Project N95 and Leveraging Airtable for Health Equity (Medium, 2024).
John Click was Chief of Staff at Project N95. He's now a DevOps / IT Platform Engineer building agentic governance infrastructure. He writes at johnclick.ai and johnclick.dev.
