Ousios / Case study / Forum for Naturals
Case study · 2026

The operational backbone for a membership network.

Forum for Naturals is a private membership network for senior marketing and sustainability leaders in the naturals industry. I built and own the systems that run it — and I'm now leading the platform rebuild.

ROLE
Systems & Ops Architect
SCOPE
Full operational backbone
STACK
Airtable · Claude · Stacker
Apps Script · Looker · Tally
STATUS
Live · rebuild underway

The problem

A specialized network runs on a lot of recurring, manual operations: agencies to review, members to match, a monthly spotlight to assemble, intake to chase, and data to keep clean across multiple systems.

Done by hand, that work doesn't just fail to scale — it drifts. A review attaches to the wrong agency, a pairing repeats, a spotlight ships late. For a network whose whole value is curation, the credibility lives in exactly those details.

The approach

Treat the whole thing as one system, not a pile of tasks. Airtable holds the data; idempotent automations move and match it; an AI layer drafts and summarizes; a member app presents the result.

Every flow is built to be safe to re-run — normalized match keys, status flags, and explicit error capture instead of blind writes. The matching is deterministic; the AI only ever handles the writing.

What's built

Five systems, one backbone.

01 — DATA

Three Airtable bases

The operational core: members, brands, agencies, reviews, resources, courses, events, and the matching system — modeled with normalized keys and rollups so the data stays filterable, not just full.

02 — TRUST

Verified-review pipeline

Reviews flow from intake into canonical records, matched on normalized email and name keys with captured record IDs. A failed match is flagged with an error note, never written silently.

03 — PUBLISHING

Self-assembling Spotlight

The monthly Agency Spotlight assembles itself: an agency submits a form, the submission is logged and tracked, and the page record builds its copy and assets — ready to render.

04 — CONNECTION

Member-matching system

Deterministic no-repeat pairings each cycle, with the outreach drafted automatically — the same primitive that became Cycle Conductor. Rules for the matching, AI for the voice.

05 — SPEED

Custom AI skill library

Six reusable Claude skills — narrative reporting, comparative analysis, wireframe-to-deck, tone-controlled outreach, multi-format orchestration, and the catalog that indexes them.

06 — REPORTING

Dashboards & tracking

Looker Studio reporting on engagement and page views, with Claude as the external AI layer for formula help and turning screenshots into stakeholder presentations.

49
Tables across
3 Airtable bases
6
Custom AI
skills built
0
Repeat pairings
per cycle
Every
Flow idempotent &
audited
On the horizon

Now leading the platform rebuild.

The next phase sunsets the off-the-shelf member app for a more controlled stack. The standing principle: document every workflow tool-agnostically first, then build against the written specs — so the tools serve the design, not the other way round.

Role-based visibility is modeled per field rather than per page, which is what makes access auditable instead of a tangle of show-hide rules. The directory and member systems are spec'd from teardowns of how the most mature directories and community platforms structure their schema, filtering, and permissions.

Auth · Clerk Data · Airtable Content · Sanity AI · Claude
Documentation phase → build phase → soft launch
Common questions

What people ask about this work.

What did you build for Forum for Naturals?

The full operational backbone: three Airtable bases, an agency directory with a verified-review pipeline, a self-assembling monthly Agency Spotlight, a deterministic member-matching system, and a custom library of reusable AI skills. I'm now leading the rebuild onto a Clerk, Airtable, and Sanity stack.

How is the review pipeline kept trustworthy?

Reviews flow from intake into Airtable, where normalized match keys link each one to the correct agency, contact, and brand records. Every automation is idempotent — it captures record IDs, tracks a status, and writes an explicit error note when a match fails, so failures are visible instead of silent.

Why rebuild the platform?

To move from an off-the-shelf member app to a more controlled stack — Clerk for auth, Airtable as the system of record, Sanity for content. The principle driving it is to document every workflow tool-agnostically first, then build against the specs, with role-based visibility modeled per field rather than per page.

Have an operation that should run itself?

This is the shape of system I build — database, automation, AI, and the member-facing result, owned as one loop end to end. If you're running an operation that deserves the same, tell me where it strains first.

Start a project ↗