TenantAtlas/specs/403-public-website-launch-readiness/research.md
ahmido b9c128163b feat: public website launch readiness updates (#394)
## Summary
- apply public website launch readiness updates across the Astro site shell, content, and navigation
- refine website components, metadata, and localization-related structure for launch prep
- update docs/content paths and smoke coverage to match the launch-ready public site state

## Scope
- touches the website app and related spec artifacts for feature 403
- does not modify `apps/platform`

## Testing
- not run in this step

Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de>
Reviewed-on: #394
2026-05-21 21:41:33 +00:00

73 lines
5.7 KiB
Markdown

# Phase 0 Research: `apps/website` Public Website Launch Readiness
## Decision: Keep the Spec 402 Astro/ScrewFast-derived foundation
**Rationale**: The active website is a standalone Astro app at `/Users/ahmeddarrazi/Documents/projects/wt-website/apps/website` with Starlight docs, sitemap generation, Tailwind v4, Preline, Lenis, and Playwright smoke tests already in place. Spec 403 is a launch-readiness pass, not another rebuild.
**Alternatives considered**:
- Rebuild the website foundation again: rejected by scope.
- Introduce a new design system or app shell: rejected because Spec 402 already selected the substrate.
- Move launch checks into the Laravel platform: rejected because `apps/platform` is out of scope.
## Decision: Treat route, CTA, metadata, and sitemap behavior as the public contract
**Rationale**: This feature has no API endpoints or product runtime entities. Public launch behavior is expressed through static pages, redirect aliases, generated metadata, navigation/footer links, docs exposure, `robots.txt`, and sitemap output.
**Alternatives considered**:
- Generate OpenAPI or GraphQL contracts: rejected because the public website exposes no API for this feature.
- Model route readiness as product runtime state: rejected because it would create unnecessary taxonomy/persistence.
## Decision: Use conservative public copy and proof-safe claim checks
**Rationale**: The spec assumes no verified customer logos, testimonials, certifications, Microsoft endorsements, uptime guarantees, compliance guarantees, recovery guarantees, self-serve billing, or account provisioning workflow. Copy and metadata must therefore stay contact/demo-oriented and avoid unsupported proof claims.
**Alternatives considered**:
- Use aspirational enterprise proof language: rejected because it creates public trust risk.
- Keep placeholder social proof from the substrate: rejected unless hidden, removed, or rewritten as neutral content.
## Decision: Keep static product previews illustrative
**Rationale**: Product-like preview content can help visitors understand Tenantial, but it must not imply live Microsoft tenant data, a running Graph integration on the website, or shared product status taxonomy.
**Alternatives considered**:
- Present previews as live tenant output: rejected because the public website has no authenticated tenant runtime.
- Remove all previews: rejected because static/demo previews are useful and allowed when clearly framed.
## Decision: Validate with website build, Playwright smoke, manual browser review, and scope checks
**Rationale**: The current package scripts support `corepack pnpm build:website` and `WEBSITE_PORT=4321 corepack pnpm --filter @tenantatlas/website test:smoke`. Playwright is already configured for desktop and mobile projects and starts the Astro preview server. These lanes prove the public static website without pulling in Laravel runtime cost.
**Alternatives considered**:
- Run Laravel/Pest/Filament tests: rejected because this feature does not touch `apps/platform`.
- Rely only on static text review: rejected because launch readiness requires browser/mobile/light/dark/overflow/CTA validation.
## Decision: Use a website-local launch-readiness note as the implementation handoff artifact
**Rationale**: FR-034 requires a launch-readiness note documenting route exposure, CTA assumptions, trust/pricing claim posture, sitemap behavior, and deployment expectations. This is a website release artifact, not product persistence.
**Alternatives considered**:
- Store launch readiness in database tables: rejected as out of scope and unnecessary.
- Skip the note and rely on PR comments: rejected because reviewers need a durable handoff artifact.
## Current Source Observations
- Rendered smoke routes currently include `/`, `/platform`, `/pricing`, `/contact`, `/trust`, `/legal`, `/privacy`, `/terms`, `/imprint`, and `/welcome-to-docs/`.
- Public Starlight docs routes also include `/guides/intro/`, `/guides/getting-started/`, `/guides/first-project-checklist/`, and `/platform/evidence-review/`; current smoke coverage only lists the docs root.
- Redirect smoke routes currently include `/product`, `/products`, `/services`, `/blog`, and `/insights`, all resolving to `/platform`.
- `/product`, `/products`, and `/services` currently use 301 redirects; `/blog` and `/insights` currently use 302 redirects. The launch note should confirm this split is intentional.
- `astro.config.mjs` filters redirect-only paths out of the generated sitemap.
- `robots.txt` points to the generated sitemap index through `import.meta.env.SITE`.
- `apps/website/src/utils/navigation.ts` still contains `socialLinks` with `#` placeholder targets; implementation should remove, hide, or replace public placeholders if they are emitted.
- Existing smoke helpers already check forbidden public terms and horizontal overflow; Spec 403 may need broader CTA, metadata, docs, sitemap, and keyboard coverage.
- Main-layout canonical URLs are page-specific, but current social metadata uses the site root for `og:url` and `twitter:url` on non-doc pages; launch implementation should make route metadata consistent.
- Current social image metadata has launch-review risk: main-layout image type is hardcoded as PNG while generated social output may be WebP, and Starlight docs metadata references `https://tenantial.com/social.webp` without an obvious matching public file.
- `/imprint` contains placeholder production details that must be replaced or made explicitly conservative before launch.
- The contact page includes a static form and `Prepare Email` submit button without a backend workflow; copy/behavior must not imply a guaranteed submission workflow.
- The footer includes an email field and `Subscribe` link to `/contact`; this should be reframed or removed to avoid implying a newsletter workflow.