MyPhotoAI · pSEO case study

When a TypeScript slug manifest beats a CMS, and when it does not

We have shipped pSEO from a TypeScript manifest (this surface) and from a headless CMS (Sanity-backed surface on a prior engagement). The TypeScript path wins under two hundred leaves with a small editorial team. The CMS path wins above that or when the editorial team is non-technical. This leaf is the comparison and the crossover analysis, with the migration sketch in section three.

By AlkenaCode engineering team

We ship programmatic SEO surfaces, AI-driven receptionists, and case-study sites for Kenyan SMEs and overseas clients. Every claim on this page traces back to shipping work, not speculation. The audit tool on /audit is the same software we use to evaluate prospective engagements.

Authors of the myphotoai.alkenacode.dev pSEO surface itself. Source code is open at github.com/Kiragu-Maina/alkenacode-family. Production deployments include agents.alkenacode.dev and home.alkenacode.dev.

Last updated:

This surface runs on a TypeScript manifest; the prior engagement we reference ran on Sanity. The migration sketch in section three is the one we wrote up for that client, abbreviated for length.

When a TypeScript slug manifest beats a CMS, and when it does not

TypeScript manifest: tight loop, strong types

The manifest is a single .ts file with a typed array of slugs. Every editorial change is a git commit; the diff shows exactly what changed. The Next.js build catches schema violations at compile time; our build-time validator catches mediocrity (citation count, body length, em-dash usage) before deploy. The loop from edit to preview is whatever your dev server's hot-reload time is, typically two to four seconds. The cost is that non-engineers cannot edit; the benefit is that the editorial state in source control is the production state, byte-for-byte, with no drift.

Headless CMS: scale and accessibility

A CMS lets a non-technical author edit a leaf without filing a PR. Above two hundred leaves with three or more authors, this is the only sustainable shape; the PR queue becomes the bottleneck otherwise. The trade-off is two surfaces of state: the CMS database and the deployed front-end. They will drift unless you wire revalidation hooks and treat the CMS as the source of truth. The drift risk is real; we have seen a Sanity-backed surface ship a half-updated set of leaves because the webhook fired before the editor finished a transaction.

The crossover point and the migration path

Our heuristic: under one hundred fifty leaves with one or two authors, TypeScript. Over two hundred leaves or three plus authors, CMS. The hundred-fifty-to-two-hundred band is a judgment call; if the authors are technical, stay on TypeScript. The migration path from TypeScript to CMS is straightforward: dump the manifest to JSON, ingest into the CMS as initial content, switch the page renderer to fetch at build time from the CMS instead of importing the manifest. The reverse migration (CMS to TypeScript) is harder because you lose the editorial UX. Pick the right shape at the start.

src/app/p/[slug]/page.tsxtsx
import { SLUGS } from "../../../../content/slugs";

export const dynamicParams = false;

export function generateStaticParams() {
  return SLUGS.map((s) => ({ slug: s.slug }));
}

export default function LeafPage({ params }: { params: { slug: string } }) {
  const leaf = SLUGS.find((s) => s.slug === params.slug);
  if (!leaf) notFound();
  // ... render the leaf
}
The leaf route's generateStaticParams reads the manifest at build time and tells Next.js which slugs to emit as static HTML.

Sources

Every claim on this page traces back to one of the verifiable sources below. Citations are publisher-stable; we avoid blog posts and other URLs that may not survive a year.

  1. Next.js docs: App Router (Next.js)
  2. Next.js docs: generateStaticParams (Next.js)
  3. Next.js docs: output option (standalone, export) (Next.js)
  4. Next.js docs: generateMetadata (Next.js)
  5. Google: creating helpful, reliable, people-first content (Google Search Central)
  6. Google Search Quality Rater Guidelines (PDF) (Google Search Central)
  7. Google: indexing overview (Google Search Central)
  8. Google: canonicalization and duplicate URLs (Google Search Central)
  9. web.dev: Lighthouse SEO audits (Chrome for Developers)
  10. Google: title link and meta description best practices (Google Search Central)
Free site auditor

See how the pattern applies to your site

The auditor uses the same evidence bundle described above (robots, sitemap, page samples) and returns a structured opinion. No signup, no email required to see results.