The 18 indexed pages on Open Alternative To are structurally identical — same template, same GitHub API data sources, same Claude Haiku-generated intro. That uniformity is useful at build time and a liability at review time. Pages that don't differ in any content requiring editorial judgment are indistinguishable from scraped mirrors.

The fix I reached for is an Astro 5 content collection for per-entry editorial takes. Here's how the pattern works and where it earns its overhead.

What content collections give you here

Astro 5 content collections are typed collections of Markdown or data files living in src/content/. You define a Zod schema in content.config.ts, and at build time Astro validates every file and gives you typed APIs — getCollection(), getEntry() — that don't compile if a file is malformed or missing an expected field.

The critical property for this use case: getEntry() returns undefined for missing entries rather than throwing. You can conditionally render editorial content only for pages that have it, with no try/catch, no file-existence check, no runtime error. The 15 pages without editorial takes render exactly as before; the 3 pages with takes get the extra section automatically at build time.

The setup

src/content/content.config.ts:

import { defineCollection, z } from "astro:content";

const perAlternativeTakes = defineCollection({
  type: "content",
  schema: z.object({
    saas_slug: z.string(),
    author: z.string(),
    last_reviewed: z.string(),
    summary: z.string().max(200),
  }),
});

export const collections = {
  "per-alternative-takes": perAlternativeTakes,
};

Files live at src/content/per-alternative-takes/{slug}.md. The {slug} matches the saas_slug in the comparison page's Turso data row — so auth0.md, datadog.md, airtable.md. The summary field is the 200-char intro line shown before the full editorial body. Everything after the frontmatter renders as standard Markdown via <take.Content />.

The page integration

In pages/alternatives/[slug].astro:

import { getEntry } from "astro:content";

const { slug } = Astro.params;
const take = await getEntry("per-alternative-takes", slug);

Then in the template:

{take && (
  <section class="mt-10 border-t border-zinc-200 dark:border-zinc-700 pt-8">
    <h2 class="text-xl font-semibold mb-2">Editor's perspective</h2>
    <p class="text-sm text-zinc-500 mb-4">
      {take.data.summary}
      <span class="ml-2">— Last reviewed {take.data.last_reviewed}</span>
    </p>
    <div class="prose dark:prose-invert max-w-none">
      <take.Content />
    </div>
  </section>
)}

That's the entire integration. No conditional imports, no dynamic requires, no feature flags. The TypeScript is clean because take is either the typed entry or undefined — the Zod schema enforces all required fields at build time, so by the time the template runs there's no need to guard against missing summary or last_reviewed.

What it actually costs to run

The Astro setup is about 30 minutes — schema definition, content.config.ts, the template conditional, and smoke-testing the build. That's not where time goes.

Each editorial take is 3-4 hours of writing and verification. The auth0 take required confirming whether AGPL §13 actually triggers when embedding ZITADEL in a closed-source SaaS (it does, specifically because SaaS users "interact with the software over a network"). The datadog take required checking whether Netdata's star count I cited matched the current GitHub figure and whether the Grafana stack sizing estimates I used were from the official docs. The airtable take required reading NocoDB's actual license files — not just the GitHub badge, which can be stale — to distinguish the AGPL core from the hosted-version terms.

At 3-4 hours each, covering all 18 curated pages in editorial depth would be 54-72 hours. That's not the near-term plan. Three takes are enough to demonstrate the pattern and differentiate a subset of pages. The Astro infrastructure is in place; I add takes when I've done the verification work, not on a publishing schedule.

When this pattern is worth it

Content collections as an editorial layer make sense when:

The content is genuinely optional per-entry. If every page should eventually have an editorial section, you're better off adding it directly to the main data model and the programmatic generation step. The content collection is for the incomplete case — where some pages have editorial depth and others don't.

The editorial content is unstructured prose. If it's structured (ratings, dates, license classifications), it belongs in Turso with the rest of the comparison data, typed as part of the main SaasEntry schema. The content collection is for markdown that doesn't fit a schema.

You have actual domain knowledge for the specific entries you're writing. Writing editorial takes for software you haven't used and haven't read deeply is worse than having no take at all. A take that gets a detail wrong — say, mischaracterizing which parts of a repo are under the enterprise license — is actively harmful to readers making deploy decisions. The editorial layer has value proportional to the accuracy of the judgment behind it.

The tradeoff I'm watching

The split between Turso (structured comparison data) and the content collection (editorial prose) creates two data sources that need to stay loosely synchronized. If a comparison page's curated status changes — say, an alternative loses stars below the 1,000 threshold and the page moves to noindex — the editorial take for that slug still exists in src/content/per-alternative-takes/. The take doesn't break anything; it just becomes orphaned content that renders on a noindex page.

For 3 takes across 18 pages this is a minor concern. At 18 takes across 80 total pages it would need explicit handling — probably a build-time check that warns when a take exists for a non-curated slug. I'll add that when the number of takes grows past single digits.

Part of an ongoing 6-month experiment running three AI-curated directory sites. The technical claims here are real; this article was AI-assisted.