Chapter 2: Requirements & Non-Functional Constraints

The remainder of the chapter expands each row.

2.2 Scale: 1,000+ pages, static + editorial mix

A 1,000-page corpus is small for a database but large for a build step, and the mix matters more than the raw count. Three sub-populations behave very differently:

• Static/marketing pages (~tens): change rarely, hand-authored, can be fully pre-rendered.
• Editorial/long-tail content (~hundreds to low thousands): the bulk of the corpus, edited by humans, frequently updated.
• Programmatic/generated pages (potentially unbounded): templated from data, where AI assistance and generation pressure the page count upward over time.

The architectural consequence is rendering strategy must be chosen per population, not for the whole site. At 1,000–5,000 pages a full static build is still fast and is the safest default; the cliff appears in the 10,000–100,000 range. Benchmarks in 2026 are blunt about this:

• Hugo (Go, single binary) builds thousands of pages in seconds and remains the raw-speed leader for very large corpora (10,000+ pages).
• Astro is the 2026 default for content-first sites — zero JS by default, excellent Core Web Vitals — but currently lacks native ISR; large incrementally-changing sites are handled via SSR plus a cache layer (e.g. Cloudflare KV) (Astro docs; LaunchFast).
• Next.js with Incremental Static Regeneration (ISR) is the escape hatch for huge or fast-changing sets: rather than pre-render all pages, you build the most-trafficked ~1,000 at build time and serve the long tail on-demand with revalidation. Vercel's own framing: 100,000 product pages at 50ms each would take ~2 hours to fully pre-render, but ISR lets the build finish in ~1 minute by deferring the rest (Vercel ISR docs).

Requirement to write down: define a full-corpus publish-time budget (e.g. "<10 minutes for a clean rebuild at 5,000 pages; <60 seconds for an incremental publish of a single edited page"). This single number quietly eliminates whole categories of architecture (a pure full-rebuild SSG fails the incremental sub-budget once the corpus is large), and it is the first place a CMS choice should be stress-tested.

2.3 Performance & Core Web Vitals

Core Web Vitals (CWV) are a confirmed Google ranking signal, folded into the page-experience signals since June 2021. The 2026 "good" thresholds, measured at the 75th percentile of real-user (CrUX field) data per URL, are:

(Google Search Central; corewebvitals.io)

INP replaced First Input Delay as a Core Web Vital in March 2024 and is the metric most sites fail today — 2026 industry analyses report ~43% of sites still miss the 200ms INP bar, making it the most-failed vital. The practical lesson for a CMS build: INP is a JavaScript-discipline problem, which is exactly why "zero-JS-by-default" frameworks (Astro, Eleventy) and islands architectures have an inherent advantage over heavy client-side React apps.

Treat CWV as a budget enforced in CI, not a thing checked once at launch. A workable performance budget for a content site:

• Total transferred JS per route ≤ ~150 KB gzipped (lower is better; islands/partial hydration help).
• LCP element is a server-rendered image or text, never lazy-loaded; images served as AVIF/WebP with explicit width/height to protect CLS.
• Lighthouse CI gate in the pipeline: fail the build if performance < 90 or any CWV regresses.
• Field-data watch: PageSpeed Insights / CrUX dashboard monitored monthly, because field data, not lab data, is what Google ranks on.

CWV are estimated to account for only ~10–15% of ranking weight — a tiebreaker, not the main event — but in 2026 they are table stakes: failing them caps the ceiling for everything else, and a slow site also degrades GEO crawl coverage and human conversion.

2.4 SEO and GEO (Generative Engine Optimization)

In 2026 discoverability is two disciplines that share infrastructure. SEO still drives organic traffic volume; GEO — getting cited inside answers from ChatGPT, Perplexity, Google AI Overviews, Gemini, and Copilot — drives high-intent, brand-shaping visibility (LLMrefs; Boston Institute of Analytics). Both impose requirements on the CMS content model and rendering layer, which is why they belong in this chapter and not as an afterthought.

Shared technical baseline (requirements):

• Server-side rendered content. AI crawlers and many SEO crawlers do not reliably execute JavaScript; important content must be in the initial HTML. This is a hard constraint on the rendering strategy chosen in §2.2.
• Structured data (JSON-LD). Schema.org markup is now the primary technical layer determining AI Overview citation eligibility — 2026 analyses report pages with valid structured data are ~2.3× more likely to be cited in AI Overviews (Stackmatix; DigitalApplied). The content model must therefore carry the fields needed to emit Article, Organization, Person (author), and BreadcrumbList schema automatically. Note the moving target: Google removed visible FAQ rich results on 7 May 2026, though FAQ schema still aids AI extraction — a reminder to treat schema as a maintained surface, not a set-and-forget tag.
• E-E-A-T signals as data. Author identity (a real Person entity with credentials), reviewer, last-updated date, and citations should be first-class fields, not free text, so they render as machine-readable author/authority signals.
• Crawler access hygiene. robots.txt must not accidentally block AI bots (GPTBot, ClaudeBot, PerplexityBot, Google-Extended); server must not 403 them.
• llms.txt — adopt with eyes open. The proposed /llms.txt (and llms-full.txt) Markdown manifest gives AI systems a clean index of key content; Anthropic and OpenAI are reportedly crawling it. But the evidence is thin — a study of ~300,000 domains found no statistical correlation between having an llms.txt file and being cited (c-sharpcorner; Lets Data Science). Requirement: generate it cheaply from the sitemap as a low-cost hedge, but do not over-invest or claim it as a ranking lever.

Multilingual SEO (overlaps with §2.5): reciprocal hreflang tags, localized titles/meta, locale-specific canonicals, and per-language sitemaps are required to avoid duplicate-content dilution across locales.

The honest framing for the project: build the infrastructure (SSR HTML, schema-from-model, clean crawler access) as hard requirements; treat the more speculative GEO tactics (llms.txt weighting, prompt-style content) as low-cost experiments with measurement, not as guarantees.

2.5 Internationalization (i18n) readiness

"i18n-ready" is cheaper to design in than to retrofit, even if the site launches in one language. The requirement is not "translate everything now" — it is "make the content model and routing locale-aware so adding a language later is configuration, not surgery."

Concrete i18n requirements for the content model and frontend:

• Locale is a first-class dimension on every translatable entry. Each entry exposes a localizations relation so the frontend can programmatically emit accurate hreflang and canonical links (Strapi 5 i18n guide; Sanity).
• A defined fallback chain. When a translation is missing, render a configured fallback locale rather than a 404 (e.g. de-AT → de → en). The fallback policy must be explicit and per-field-aware (some fields fall back, some — like price or legal text — must not).
• Locale-aware routing. Decide the URL strategy up front: sub-path (/de/…, recommended default for SEO and simplicity), subdomain, or ccTLD. Sub-paths are the lowest-friction choice for a single-codebase content site.
• Externalized, structured strings for UI chrome (not just body content), date/number/currency formatting via the platform's Intl support, and RTL-capable templates.
• Per-locale builds that don't over-fetch. Query one locale at a time so missing translations don't inflate payloads and TTFB stays low — i18n and CWV are coupled (Astro i18n 2026 guide).

Even a single-language launch should ship with the locale field present and the fallback chain configured; this is the single highest-leverage "readiness" decision in the schema.

2.6 Multi-author workflow & content governance

A 1,000+ page editorial corpus implies multiple contributors, which turns content into a governance problem. Requirements:

• Role-based access control with at least author / editor / publisher(admin) tiers; least-privilege by default.
• A draft → review → publish workflow with an explicit gate so no unreviewed content reaches production. (Enterprise tiers of SaaS CMSs — e.g. Strapi's $299/mo plan, Contentful's higher tiers — gate workflow, SSO, and audit logs behind paid plans; this is a cost line, see §2.8.)
• Audit trail / version history on every entry (who changed what, when; rollback).
• Scheduled publishing and content expiry.
• Required-field enforcement for accessibility and SEO (alt text, meta description, author) — the CMS should make a non-compliant page impossible to publish, which is far cheaper than auditing after the fact.

These requirements interact with the build-vs-buy decision: mature editorial workflow is one of the strongest arguments for buying (it is undifferentiated, hard to build well, and expensive to maintain).

2.7 Accessibility & security baselines

Accessibility is now a legal requirement, not a nicety. The European Accessibility Act (EAA) enforcement deadline was 28 June 2025 and is now actively enforced across EU member states; it covers e-commerce, banking, transport ticketing, telecoms, and audiovisual media, and applies to non-EU providers selling into the EU (Level Access; OneTrust). The technical standard is EN 301 549, which currently maps to WCAG 2.1 AA and is being updated toward WCAG 2.2 AA. Penalties vary by member state, roughly €5,000–€500,000.

Requirement: target WCAG 2.2 Level AA (it is a superset of 2.1 AA and future-proofs against the EN 301 549 update). Enforce a subset automatically (axe-core / Pa11y in CI: 0 critical violations as a build gate) and budget for at least one manual audit (keyboard navigation, screen-reader pass, contrast, focus order) before launch — automated tools catch only ~30–40% of issues. Bake required alt-text and semantic-heading discipline into the content model (§2.6).

Security baseline (expanded in later chapters; stated here as requirements):

• HTTPS everywhere; HSTS; modern security headers (CSP, X-Content-Type-Options, Referrer-Policy).
• Authentication for the CMS admin behind SSO/MFA; no shared editor accounts.
• Dependency and supply-chain scanning in CI; pinned, reviewed dependencies.
• Principle of least privilege on API tokens (read-only delivery tokens vs. management tokens kept server-side).
• A clear separation between the editing surface (authenticated, can be locked down hard) and the delivery surface (public, cacheable, ideally static and thus low-attack-surface). A statically-rendered delivery layer is itself a security feature: there is no live database to inject into at request time.

2.8 Budget & 5-year TCO

Budget is a non-functional requirement and the one most often understated, because the sticker price (license or "free" self-host) is a fraction of the real cost. The 2026 consensus framing: five-year TCO is the only honest lens, and hidden integration, training, and operations can add ~150–200% on top of a "buy" license fee over time (Neontri; Oceanscode CFO guide). For enterprise CMS, operational cost (the daily labor of creating/editing/publishing) is typically the largest slice of TCO, not licensing.

Indicative 2026 pricing for the headless options most relevant to an owned, AI-native build:

(Pricing from buildmvpfast.com Feb-2026 tracker, Strapi, Cosmic, Pooya Golchian comparisons — verify against vendor pages before committing; these tiers churn.)

The crucial TCO insight: "self-hosted and free" is rarely the cheapest. While Strapi-self-hosted has a $0 license, operating it reliably (upgrades, security patches, uptime, backups, scaling) consumes an estimated 0.25–0.5 FTE/year — $50K–$100K of senior engineering at 2026 rates — which often exceeds a SaaS subscription. Conversely, SaaS per-seat and usage pricing can balloon as authors and traffic grow. There is no universally cheap option; the cheapest option is the one whose cost shape matches your growth (predictable users → per-seat is fine; spiky/unbounded pages → watch usage metering).

Requirement: model 5-year TCO across at least three scenarios (build, buy-SaaS, hybrid) including license, implementation, operations (FTE), integration, training, and an exit/migration reserve. Write the budget ceiling as a hard number and re-check it at the 6- and 12-month marks.

2.9 Build vs. buy: a decision framework that stays honest

The 2026 consensus principle is clean: buy for commodity, build for differentiation — buy the standard parts of your business, build the parts that make you different (Neontri 3-model framework; McCary Group). For a CMS, the "commodity" parts are editorial workflow, auth, media handling, and CDN delivery; the "differentiating" parts are usually the AI features and the specific content model. A hybrid ("composable") posture — buy a headless content store, build the AI layer and the frontend around it — is the default recommendation for most teams, and is the architecture this report develops in later chapters.

A weighted scoring rubric keeps the choice from becoming a personality contest. Score each candidate (custom build / SaaS / hybrid) 1–5 on each vector, multiply by a weight (1–3), and total:

(Adapted from Neontri and AgileSoftLabs 2026 frameworks.)

Keep-it-honest guardrails — the practices that prevent a build-vs-buy decision from quietly rotting:

1. Run an export/exit drill before signing. Verify you can get all content out in a usable format (structured export, media). If you can't, the "owned" goal is an illusion regardless of who hosts it.
2. Score against budgets, not demos. Measure every candidate against the §2.1–2.8 budgets on your corpus, not the vendor's marketing benchmark.
3. Count the FTE. Always include operational labor in the "build/self-host" column; the $0 license line is the most expensive line if you forget the people behind it.
4. Separate reversible from irreversible decisions. The content model, the customer/identity namespace, and the URL/locale strategy are expensive to change later — spend the up-front thinking there; the frontend framework is comparatively cheap to swap.
5. Re-evaluate on a schedule. Pricing tiers, framework capabilities (Astro ISR, Next.js), and the GEO landscape are all moving fast in 2026 — set a quarterly review of the constraints in this chapter.

Key Takeaways

• Write non-functional requirements as numeric budgets enforced in CI before choosing a stack — budgets are vendor-neutral and force apples-to-apples comparison.
• Rendering strategy must be chosen per content population; at 1,000–5,000 pages full static build is safe, but define both a full-rebuild and an incremental-publish time budget to expose the scaling cliff (ISR/Next.js or Hugo speed for the large/long-tail case).
• 2026 Core Web Vitals "good" bars: LCP ≤2.5s, INP ≤200ms, CLS ≤0.1 at the 75th CrUX percentile; INP (a JS-discipline problem, ~43% of sites fail it) favors zero-JS/islands frameworks like Astro.
• SEO and GEO share infrastructure: server-rendered HTML + JSON-LD schema are hard requirements (schema-marked pages ~2.3× more likely cited in AI Overviews); treat llms.txt as a cheap hedge, not a proven lever (no measured citation correlation across 300K domains).
• Make the content model i18n-ready from day one (locale as a first-class field, explicit fallback chain, sub-path routing, reciprocal hreflang) even for a single-language launch — retrofitting is far more expensive.
• WCAG 2.2 AA is now legally enforced under the EAA (deadline 28 June 2025, EN 301 549, fines up to ~€500K); enforce a subset via axe-core in CI and budget a manual audit.
• 5-year TCO is the only honest budget lens; "free self-hosted" CMS typically costs 0.25–0.5 FTE/yr ($50K–$100K) to operate — often more than SaaS. Match the cost shape to your growth.
• Use "buy for commodity, build for differentiation" with a weighted scoring rubric; the default for AI-native sites is hybrid/composable (buy the content store, build the AI layer and frontend).
• Keep the decision honest: run an export/exit drill before signing, count the FTE, score against your own corpus, and protect the irreversible decisions (content model, identity namespace, URL/locale strategy).

Key References

• Google Search Central. Understanding Core Web Vitals and Google Search Results. 2026. https://developers.google.com/search/docs/appearance/core-web-vitals — Authoritative LCP/INP/CLS thresholds and 75th-percentile CrUX evaluation method.
• corewebvitals.io. What Are the Core Web Vitals? LCP, INP & CLS Explained (2026). 2026. https://www.corewebvitals.io/core-web-vitals — Current thresholds and pass criteria; INP failure rates.
• DigitalApplied. Core Web Vitals 2026: INP, LCP & CLS Optimization. 2026. https://www.digitalapplied.com/blog/core-web-vitals-2026-inp-lcp-cls-optimization-guide — 2026 weighting and INP-as-most-failed-vital data.
• LLMrefs. Generative Engine Optimization (GEO): The 2026 Guide to AI Search Visibility. 2026. https://llmrefs.com/generative-engine-optimization — GEO definition, target engines, SEO-vs-GEO split.
• C# Corner. LLMs.txt Explained: The Ultimate 2026 Guide to AI Search, GEO, AI Crawlers, and LLM Optimization. 2026. https://www.c-sharpcorner.com/article/llms-txt-explained-the-ultimate-2026-guide-to-ai-search-geo-ai-crawlers-and/ — llms.txt mechanics and the 300K-domain no-correlation finding.
• Stackmatix. Structured Data AI Search: Schema Markup Guide (2026). 2026. https://www.stackmatix.com/blog/structured-data-ai-search — Schema as primary AI Overview citation layer; 2.3× citation figure; FAQ rich-result removal (7 May 2026).
• Level Access. European Accessibility Act 2026: EAA Compliance Guide. 2026. https://www.levelaccess.com/compliance-overview/european-accessibility-act-eaa/ — EAA scope, 28 June 2025 deadline, enforcement and penalties.
• OneTrust. Understanding the European Accessibility Act and WCAG 2.2. 2025. https://www.onetrust.com/blog/understanding-the-european-accessibility-act-and-wcag-22/ — EN 301 549 mapping to WCAG 2.1/2.2 AA.
• W3C WAI. WCAG 2 Overview. 2026. https://www.w3.org/WAI/standards-guidelines/wcag/ — Canonical WCAG 2.2 success criteria.
• Neontri. Build vs. Buy Software: A 3-Model Decision Framework. 2026. https://neontri.com/blog/build-vs-buy-software/ — Buy-commodity/build-differentiation principle and hybrid model.
• Oceanscode. Build vs. Buy in 2026: A CFO's Guide to Total Cost of Ownership (TCO). 2026. https://oceanscode.com/blog/build-vs-buy-in-2026-a-cfos-guide-to-total-cost-of-ownership-tco — 150–200% hidden-cost-over-license framing.
• Pooya Golchian. Contentful vs Sanity vs Strapi vs Payload 2026. 2026. https://pooya.blog/blog/contentful-vs-sanity-vs-strapi-comparison-2026/ — Pricing tiers and the 0.25–0.5 FTE/$50K–$100K self-host operating-cost estimate.
• buildmvpfast.com. Headless CMS Pricing Comparison (February 2026). 2026. https://www.buildmvpfast.com/api-costs/cms — Tracked Sanity/Contentful/Strapi/Payload pricing.
• Vercel. Incremental Static Regeneration (ISR). 2026. https://vercel.com/docs/incremental-static-regeneration — ISR at scale; the 100K-pages build-time example.
• Strapi. Strapi 5 i18n Guide: Multilingual SEO & Internationalization. 2026. https://strapi.io/blog/strapi-5-i18n-complete-guide — Locale-as-field, fallback, localizations for hreflang generation.