TenantAtlas/specs/409-evaluation-procurement-rollout/research.md

Research: Evaluation, Procurement & Rollout Readiness Website Surface

Decision: Use /evaluierung and /en/evaluation

Rationale: The current public website already uses root-level buyer and commercial routes such as /contact, /pricing, and /trust, with English counterparts under /en/*. The evaluation journey spans demo, pilot, trust, and procurement readiness rather than one product feature, so it fits the top-level buyer-route family better than a nested /platform/* path.

Alternatives considered:

• /platform/evaluation: too tightly nested under product detail for a broader buyer-readiness flow.
• /procurement: too narrow relative to evaluation and rollout readiness.
• /start or /demo-pilot: weaker SEO and weaker alignment with the existing public route family.

Decision: Reuse the localized thin-route plus shared-page-component pattern

Rationale: Existing public pages already use thin locale route files plus shared page components, for example platform.astro, trust.astro, contact.astro, and their English wrappers. The evaluation page is section-heavy in both German and English, so one shared EvaluationPage.astro is the narrowest way to avoid duplicating large amounts of markup.

Alternatives considered:

• Duplicate full German and English route markup: acceptable, but repetitive and harder to maintain.
• MDX/docs content route: mismatched with the current marketing-page CTA and metadata pattern.
• Inline-only homepage or platform section: weaker SEO, weaker smoke coverage, and weaker discoverability.

Decision: Keep all localized page copy in site-copy.ts

Rationale: The website already centralizes public copy, metadata, navigation labels, footer links, homepage copy, platform copy, trust copy, review-pack copy, and use-case copy in apps/website/src/data_files/site-copy.ts. Adding a dedicated evaluation section there keeps the new page aligned with the existing locale strategy and avoids a second content source.

Alternatives considered:

• Page-local constants: simpler for one file, but weaker for German/English parity and CTA consistency.
• Separate JSON or YAML content file: splits public copy away from the current marketing-content source of truth.
• Runtime content source or CMS: out of scope for a website-only feature.

Decision: Use /contact as the real conversion path for demo, pilot, and security-document requests

Rationale: The existing public site already routes buyer-facing demo and walkthrough CTAs to /contact and /en/contact. The current public CTA pattern is route-based rather than mailto:-based, so Demo buchen, Pilot anfragen, and Security-Unterlagen anfragen should all map to the same real contact destination unless implementation discovers another real route.

Alternatives considered:

• mailto: links: technically possible, but not the prevailing public CTA pattern.
• Fake demo-booking widget: explicitly forbidden.
• New dedicated request form route: out of scope unless it already exists.

Decision: Keep discovery contextual and global, but skip a new main-nav item

Rationale: The current main nav is already dense. The stronger discovery path is contextual: homepage teaser, platform-page teaser, review-pack page crosslink, MSP page crosslink, Mittelstand page crosslink, and a footer link for global reachability.

Alternatives considered:

• Main-nav item: globally visible, but too expensive for current IA density.
• Footer only: too weak for a commercially important page.
• Homepage/platform only: helpful, but weaker for audience-specific discovery.

Decision: Reuse existing smoke helpers and route metadata inventory as the narrowest proof

Rationale: apps/website/tests/smoke/public-routes.spec.ts and apps/website/tests/smoke/smoke-helpers.ts already validate route rendering, metadata, placeholder-link bans, forbidden public claims, trust handoffs, and layout stability. Extending those tests is the narrowest proof for this feature.

Alternatives considered:

• Manual-only browser review: insufficient for metadata and claim-guardrail regressions.
• New unit tests for copy objects: more brittle than public-route smoke for this use case.
• Platform-side tests: wrong layer because apps/platform is explicitly out of scope.

Decision: Use only existing website commands for validation

Rationale: apps/website/package.json currently exposes build, test, test:smoke, format:check, and preview. The plan must not invent a check script because astro check already runs inside build.

Alternatives considered:

• pnpm --filter @tenantatlas/website check: not present.
• Root script changes: out of scope and would break workspace contracts.
• Platform/Sail validation: wrong scope for a static website-only page.

Decision: Treat static claim scans as implementation blockers

Rationale: The main risk in this feature is overclaiming rather than runtime breakage. Static scans over apps/website/src, apps/website/public, and optionally apps/website/dist should block placeholder links, internal architecture jargon, false legal or provider claims, fake self-service promises, and invented downloads.

Alternatives considered:

• Code review only: too easy to miss metadata or generated-output regressions.
• New custom linter: too heavy for one bounded website feature.
• Placeholder-link scan only: insufficient because the main risk is claim language.

Decision: Reuse existing trust and review-story routes as adjacent handoffs

Rationale: /trust, /en/trust, /platform/review-packs, and their locale-aware discovery surfaces already exist today. They are the safest real destinations for trust, security, privacy, and review-story follow-up questions from the new page.

Alternatives considered:

• Omit trust and review crosslinks: safer, but weaker than the spec goal of connecting evaluation readiness to adjacent proof surfaces.
• Invent a security-pack download or procurement portal route: explicitly forbidden.

Decision: Keep the docs evaluation checklist as documentation, not as the feature route

Rationale: The docs route /guides/first-project-checklist/ already touches evaluation language, but it is a documentation asset rather than a buyer-facing public conversion page. The new route should sit in the marketing/site IA, not inside docs.

Alternatives considered:

• Reusing the docs route as the public destination: wrong tone, weaker CTA handling, and weaker buyer-path visibility.
• Linking only to docs from existing marketing pages: too indirect for the primary sales goal.