PR1: Static-first public landing page

Guide borrowers in, then hand them off cleanly to the app.

This first cut gives the repo a dedicated public-site workspace, a visible Launch App path, and placeholder surfaces for the public read model and store CTAs that later PRs can wire without reshaping the page.

Launch App See the next public data surfaces

Rendering Mode

Static

Pre-rendered output for CDN-friendly hosting.

App Handoff

Launch App

Canonical CTA remains available on every screen size.

Public Data

Placeholder

Reserved for the future anonymous landing-data contract.

Separate from Flutter web runtime Stage-aware marketing config exported from infra Static build output in marketing/build/jaspr Repo-owned npm commands for dev, build, preview, and test

site-staging.checkmyrate.ca -> app-staging.checkmyrate.ca

Separate deployable, deliberate handoff

The marketing site stays static-first and repo-owned, while the authenticated experience remains on the separate app domain.

Abstract illustration representing public marketing content handing off to the app.

Stage-aware site origin

Launch App CTA contract

Future public snapshot widgets

Product Summary

Explain the workflow before the browser ever reaches app runtime.

The landing page focuses on what the product does, why the split deployment matters, and where later PRs will attach public metrics without exposing authenticated APIs.

Clear first-touch story

Explain how CheckMyRate moves mortgage intake forward.

The landing page sets product expectations before a user enters the authenticated app, which keeps public marketing and app runtime concerns cleanly separated.

Static-first foundation

Ship a CDN-friendly artifact before adding runtime complexity.

The workspace builds to static output, giving later hosting and promotion work a stable artifact without introducing server rendering or CMS plumbing.

Future-proof layout

Reserve the slots that later PRs will populate with public data.

The layout already includes dedicated surfaces for public landing metrics and store CTAs so later work can wire contract data instead of redesigning the page.

Dynamic Modules

Reserve the homepage slots for anonymous public data.

These cards mark the surfaces where the later landing-data contract will plug in. Nothing here depends on authenticated state or backend coupling yet.

PR3

Rate snapshot module

Reserved for the anonymous landing-data payload that will surface aggregated rate and offer summaries without exposing authenticated protobuf APIs.

PR3

Coverage and lender summary

Reserved for public, aggregated breadth indicators that explain where CheckMyRate can help without leaking customer-specific state.

PR5

Immutable artifact callout

Reserved for the later tested-commit promotion story once the marketing site is emitted and deployed as a first-class release artifact.

Store Download CTAs

Keep Launch App canonical and treat store buttons as additive.

The store-download area is wired to the generated stage-aware config contract, but the public App Store and Google Play listing URLs are still pending validation before this PR can be considered complete.

iOS

PR2

App Store listing not live yet

This slot is intentionally unresolved until the public App Store listing URL is validated and committed through the generated marketing-site config contract.

App Store Listing Pending

Android

PR2

Google Play listing not live yet

This slot is intentionally unresolved until the public Google Play listing URL is validated and committed through the generated marketing-site config contract.

Google Play Listing Pending

The generated contract already owns the stage app origin, canonical site origin, and future landing-data URL. PR2 remains open until the live App Store and Google Play listing URLs are validated and filled into that same contract. PR6 will finish the user-facing store UX after that.