One Pipeline, Eleven Brands: Airtable + Next.js

Running eleven brands means eleven content problems. Eleven voices, eleven audiences, eleven sets of compliance rules — and, if you are not careful, eleven separate publishing setups to maintain.

We went the other way. One pipeline, one renderer, eleven namespaces. Here is how it is put together and which decisions turned out to matter.

The shape of the thing

There are three layers, and each one does exactly one job.

Airtable is the source of truth. Nine linked tables hold everything: the brands themselves, content ideas, research sources, the master content record, channel-specific cuts of that content, media assets, and the publishing queue.

Next.js on Vercel is the renderer. It reads Airtable, joins the records in memory, and renders static pages. It never writes back. That one-way constraint keeps the whole thing debuggable — when a page looks wrong, the problem is in the data or the template, never in some third place where the two got out of sync.

Human approval sits between the two. Nothing reaches the renderer without a person saying yes.

Three gates, not one

The approval design is the part worth stealing.

Most content systems have a single review step at the end, which is the most expensive possible place to catch a problem. By then you have paid for research, drafting, editing, and image generation on something that should have died as an idea.

So there are three:

• Gate 1 — before research. Is this idea worth spending on at all?
• Gate 2 — before the content fans out. Is the master draft good? This is where voice, accuracy, and unsupported claims get caught, before that draft becomes an article plus a video script plus five social cuts.
• Gate 3 — before it goes live. Final check on the specific thing being published to the specific place.

Each gate records who approved it and when. Rejecting at Gate 1 costs nothing. Rejecting at Gate 3 costs everything upstream. Cheap failure early is the entire design goal.

URL routing from a self-reference

Every brand gets its own namespace:

buildpub.blog/golden-squirrel-ai/{slug}
buildpub.blog/elaiv8/{slug}

But some brands have sub-brands — personas or product lines that need their own space without becoming separate publications. That needs a third segment:

buildpub.blog/{parent}/{child}/{slug}

The tempting fix is a second route and a second set of templates. The better fix is a self-referencing link field on the publications table. A brand optionally points at its parent brand. Path assembly then walks up one level:

const segments = [];
if (publication.parentBuilder) {
  segments.push(parent.sectionPath);
}
segments.push(publication.sectionPath);
segments.push(contentPackage.slug);

One catch-all route handles both depths. Adding a sub-brand is a field edit, not a deploy.

One trap worth flagging: if a path segment is stored with a leading slash and you join naively, you produce a double slash. Next.js URL-encodes it into %2F, and every page silently 404s while the build reports success. Normalize your segments, and add a build-time assertion that no segment contains a slash. It will save you an afternoon.

Why there is no publish webhook

The obvious design is: approval fires a webhook, the site rebuilds, the post appears. We built that, then deleted it.

Incremental static regeneration already covers the case. A newly approved post renders on its first request. Index pages, the sitemap, and the crawler-facing summary file refresh on a timer. The worst case is that a listing page lags by up to an hour — which, for a blog, is not a real problem. Nobody is refreshing your index page waiting for a post to appear, and search crawlers are not that fast either.

That is one webhook, one secret, one endpoint, and one class of silent failure that does not exist. The mechanism that fires reliably is the one that does not exist.

Structured for machines twice over

Every post carries two summaries.

The meta description is for humans scanning search results — persuasive, benefit-led, under 160 characters.

The LLM summary is for machines. It is plain, factual, and free of marketing voice, and it feeds a /llms.txt file at each brand's root. When a language model ingests the site, it gets a clean statement of what each article actually establishes rather than a sales pitch it has to see through.

These are different jobs. Writing one and reusing it for both does neither well.

What we would tell you to copy

• Separate the master content from its channel cuts. One canonical version, many derived versions. Never edit the derivatives.
• Put your approval gates where failure is cheap, not where it is convenient.
• Model hierarchy with a self-reference before you write a second route.
• Skip the webhook until staleness is an actual complaint rather than a hypothetical one.

The unglamorous conclusion: most of the leverage came from deciding what not to build.