Skip to content

Purpose note: “YC / marketing SPA” vs what we actually run

Decision / finding

There is no separate YC or marketing SPA product. Investment and risk should be framed around three real surfaces, not a fourth phantom app.

Surface Business job Stack (summary)
Public marketing site Brand, story, team, contact, point people to the product Multi-page site (Razor + htmx), Cloud Run ww-site
Cloud product (incl. YC pilot) Let invited reviewers and team use the product in a browser Angular product UI + API, Cloud Run app service (ww-team on the env ladder)
Audience-filtered docs Share selected technical/plain docs with YC vs team without opening everything Manifest audiences + session gate inside the cloud product

yc-reviewer is an access audience (invitation/session policy and docs allowlist), not a product SKU that implies its own SPA codebase.

Why people ask for a “YC SPA”

Common motives (valid goals, wrong architecture label):

  1. Give YC a clean, frozen review experience — product immutability during review, not a different UI stack.
  2. Show marketing story without shipping the full desktop installer — the public MPA already does brochure; the cloud product does interactive demo under invite.
  3. Share docs safely — per-document audiences (yc-reviewer / team-test) on hosted docs, not a marketing SPA.
  4. Historical design language — WingCMS design materials discussed optional “SPA mounts” on marketing pages; that is design aspiration, not shipped marketing architecture. Standing strategy keeps content site = MPA, product = Angular SPA.

What “good” looks like for YC review (business view)

  1. Marketing site tells the story and links YC reviewers to the app entry.
  2. Invitation codes partition YC from team workspaces; each redemption stays private.
  3. Docs pack exposes only the paths listed for yc-reviewer in the cloud docs manifest.
  4. Freeze / change control (when used) freezes the reviewed product image, not a separate SPA project. Historical release notes describe a frozen ww-yc service; the committed environment ladder currently places both invite audiences on ww-team. Ops must treat live freeze topology as a verify item, not a slogan.

Cost and complexity implications

  • Do not fund a parallel marketing SPA “for YC consistency” with the Angular app. That duplicates stacks and breaks the MPA SEO/ops model (see mpa-strategy.md).
  • Do fund clear invite ops, audience isolation, docs allowlists, and explicit freeze receipts when a review window requires immutability.
  • Confusion cost: calling the cloud product “the YC SPA” hides that desktop and cloud share one Angular codebase and that marketing is a different deployable (ww-site).

Risks if the myth ships as a project

Risk Why it hurts
Second frontend for marketing Staffing, CSP, SEO, and CMS workflows already optimized for MPA
Docs-only audience mistaken for whole YC product Reviewers need the product under invite, not only markdown
Freeze story tied to a non-existent app Release reliability and audit trails must name real Cloud Run services/images
Design-doc SPA mounts treated as backlog “must ship” Security reviews already treated SPA-mount content as high-risk injection surface; v1 CMS scope closed much of that by not shipping SPA composition

TODO(verify)

  • Live topology: separate frozen YC Cloud Run service vs single app service with dual invitations (affects how freeze is explained to partners).
  • Which docs are actually in the production image’s cloud-docs-manifest.json for a given freeze (manifest in git may lag).
  • Whether external YC packet materials still use the phrase “SPA” in a way that should be retconned to “cloud product + docs.”

Bottom line

Purpose of this note: stop planning and buying work against a non-existent YC/marketing SPA. YC is served by the public MPA door, the shared product SPA under invite audience yc-reviewer, and manifest-gated docs. Anything else is naming drift or future design, not current product architecture.