Domain launch control
Keep the public demo, Marketplace 1.0 product, and contact property on separate deployments with independent rollback paths.
Current domain posture
- pupmkt.com is the interactive public demo. Marketplace 1.0 is a separate product and deployment, not a mirrored demo URL.
- powerupmarketplace.com uses a separate noindex contact package and does not host transactional marketplace claims.
- Release evidence records package hashes, file counts, deploy/build IDs, domain mapping and rollback targets.
DNS and cutover controls
- The canonical domain attaches only after the identical source package passes preview checks.
- Apex and www behavior, certificate state, HTTP-to-HTTPS redirects, contact proxy, social assets and unknown-route handling are checked after cutover.
- The prior placeholder site and product deploy IDs are retained so the domain and content can be restored independently.
SSL and Redirects
- Launch needs certificate issuance, HTTP-to-HTTPS redirect, apex and www behavior, and route fallback checks.
- Redirect rules should not hide broken pages by sending missing routes to the homepage during QA.
- Every public route should return the expected title, canonical URL, no mixed content, and usable assets.
Indexing release gate
- Only the truthful PUPMKT landing page is indexable and present in the sitemap.
- Sample inventory, account, transaction, operator, store and readiness routes remain noindex; noindex is never treated as authorization.
- The contact property remains noindex so it supports private outreach without competing with the canonical product.
Contact-property rules
- The contact site stays brand-light, noindex and free of live transaction, inventory or affiliation claims.
- Its form uses the same protected Supabase backend while the recipient and provider credentials stay server-only.
- Contact-site updates use a separate reviewed package and rollback history from the product.
Monitoring and Notices
- Launch needs uptime checks, certificate checks, redirect checks, indexing checks, provider contacts, and support escalation owners.
- Owners should decide which customer notices are required if domain, checkout, messages, or pickup routes have an outage.
- Incident review should preserve deploy ID, DNS state, affected routes, customer impact, and rollback decision.
Launch Approval
- Owner sign-off should name the public domain, redirect behavior, noindex release, sitemap scope, support staffing, and rollback owner.
- The launch decision record should list any blocked domains, deferred routes, provider gaps, or pages that must stay private.
- Approval should not proceed if the scoped package includes workspace internals, secrets, docs, migrations, or unrelated files.
Rollback Checklist
- Rollback should be able to detach custom domains, restore placeholder content, reapply noindex controls, and pause sitemap updates.
- Owner review should confirm how long DNS changes may take to settle and who verifies the live state after rollback.
- Rollback evidence should be captured in owner handoff, service health, search indexing, and launch decision routes.
Migration Readiness
Redirect plan, customer notices, historical records, support continuity, and cutover gates.
Go-Live Rehearsal
Practice route checks, DNS rollback, noindex safety, owner approval, and evidence capture.
Setup Center
Brand, domains, categories, seller programs, fees, roles, hubs, and launch controls.
Owner Handoff
Evidence bundle, placeholder domains, package safety, acceptance checks, and ownership.
Search Indexing
Noindex posture, public page scope, private route rules, sitemap, and rollback.
Traffic Protection
Crawler controls, rate limits, request protection, secure headers, monitoring, and rollback.
Service Health
Route checks, provider checks, support coverage, monitoring, and launch approval.
Security Response
Provider incidents, affected routes, customer notices, evidence, and rollback.
Launch Decision
Approval scope, blockers, rollback controls, evidence checklist, and owner sign-off.
Integration Evidence
Package boundary, noindex controls, deploy evidence, guard checks, and route QA.
Service Activation
Checkout, identity, notifications, media, carriers, support, and launch guardrails.
PUPMKT 1.0 state
One product, one canonical URL, one exact reference.
The canonical and Netlify product URLs serve the same reviewed build. The separate contact domain remains noindex, non-transactional, and independently deployable.
Live integration state
Domains are ready before commerce is enabled.
Identity, billing, publisher transfers, store participation, carrier operations, support and incident ownership each require independent approval before their feature flags move from demo to remote.