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 over the past year I rebuilt the whole backbone off its off-the-shelf tooling onto a stack I control end to end.
Forum for Naturals is an Ousios client. I am also its Operations Manager, so this case study describes systems I both built and use daily.
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 tooling had its own version of the same problem. A no-code base and a hosted member app are fast to start and slow to trust: no version control, no test gate, no way to prove a change was safe before it reached members. Every fix was a live edit.
The approach
Document every workflow tool-agnostically first, then build against the written spec. The specs came before the schema, and the schema before the screens, so the tools served the design instead of the other way round.
Then make correctness structural rather than careful. Every record write runs inside a transaction, so the write, its audit row, and its links land together or not at all. Every schema change ships as a numbered migration with a sequence guard. Nine quality gates run from one command before a release, four of them automatically on every push. The matching logic is deterministic by design, and any AI layer is built to handle the writing only, never a decision about where a record goes.
Six systems, one backbone.
One system of record, not three bases
The system of record is now Postgres: members, brands, agencies, reviews, resources, courses, events, and the matching system in a single relational schema with real constraints and a full audit trail. 37 numbered migrations, each sequence-checked before it can apply.
Data Studio
A custom admin application: a registry-driven interface over every table, with per-field role-based visibility, linked-record navigation, import/export, and an audit log. Access is modeled per field rather than per page, which is what makes it auditable instead of a tangle of show-hide rules.
15 guided workflows
The recurring work runs as guided flows rather than freehand edits: onboard a member, publish an agency review, change a brand's status, file and attach a resource, coordinate a virtual coffee, run a pairing cycle. Each writes through the transactional record path, so the write, its audit row, and its links land together or not at all. The pairing cycle stays deterministic, and produces no repeat pairings within a cycle.
The member portal
A second application that reads the admin database directly: no API layer and no sync job. A correction made in the admin studio reaches the portal within a sixty-second read cache, with no deploy and nothing to drift. The portal keeps a second database of its own for community data. It mounts into the marketing site at a single path, so there's no seam between the public site and the member area.
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 explicit error note, never written silently, and an intake guard distinguishes a genuine refusal from a misconfiguration, so a typo can't quietly reject a queue.
Nine gates, one command
Types, unit, API, end-to-end, accessibility, performance, security, visual regression, and migration sequence. All nine run from a single command before a release, and four of them run automatically on every push. The point of one runnable command is that the checks don't live in one person's head.
in production
shipped
the release harness
applications
What's left is the behaviour layer.
The data moved; the automations that acted on it are moving next. Thirty-one automations, nineteen of them live and firing, plus three public intake forms remain on the legacy platform, and each one gets the same treatment the data got: documented against observed behaviour first, rebuilt against the spec, verified in production, and only then switched off at the source.
A third Airtable base is still outstanding too. The cutover covered the two production bases; a separate ratings base holds 184 questionnaire records whose review content already mirrors into the migrated data, but whose scoring apparatus does not. It moves on the same terms as everything else.
The principle doesn't change. Nothing is retired until its replacement has been watched doing the job.
What people ask about this work.
What did you build for Forum for Naturals?
The full operational backbone, then its replacement. The original: three Airtable bases, an agency directory with a verified-review pipeline, a self-assembling monthly Agency Spotlight, and a deterministic member-matching system. The rebuild: two production Next.js applications, an admin Data Studio and a member portal, with the portal reading the admin's Postgres database directly, 15 guided workflows, per-field role-based access, and a nine-gate quality harness.
Why rebuild the platform?
To trade speed-to-start for the ability to prove a change is safe. A no-code base and a hosted member app have no version control, no tests, and no staging: every fix is a live edit. The rebuild puts the whole system under source control with a migration ladder and nine gates, so changes are reviewable, reversible, and auditable.
How is the review pipeline kept trustworthy?
Reviews are linked to the correct agency, contact, and brand records on normalized match keys, with the record IDs captured. Every automation is idempotent: it tracks a status and writes an explicit error note when a match fails, so failures are visible instead of silent. Record writes run inside transactions, so a partial run leaves nothing half-applied.
How did you migrate without losing data?
By diffing record ID sets rather than record counts. A count that matches on both sides proves nothing: equal numbers of additions and deletions cancel out and read as agreement. Comparing the actual sets surfaced records a count-based check had passed clean. The final reconciliation covered 38 mapped tables across the two production bases and closed at zero unexplained deltas, with all 2,876 distinct attachment URLs verified reachable and no expiring links left anywhere in the new system.
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.
Book a 30-min discovery call ↗or email kira@ousios.dev