168 lines
4.0 KiB
Markdown
168 lines
4.0 KiB
Markdown
|
|
# Phase 3 - Launch Readiness and Hardening
|
||
|
|
|
||
|
|
Duration: 2-4 weeks
|
||
|
|
Primary owner: Full stack + operations focus
|
||
|
|
|
||
|
|
## 1. Objective
|
||
|
|
|
||
|
|
Prepare Kalei for real users with production safeguards:
|
||
|
|
|
||
|
|
- safety policy completion and crisis flow readiness
|
||
|
|
- subscription and entitlement reliability
|
||
|
|
- app and API operational stability
|
||
|
|
- privacy and compliance basics for app store approval
|
||
|
|
|
||
|
|
## 2. Entry Criteria
|
||
|
|
|
||
|
|
Phase 2 exit checklist complete.
|
||
|
|
|
||
|
|
## 3. Scope
|
||
|
|
|
||
|
|
## 3.1 Safety and Trust Hardening
|
||
|
|
|
||
|
|
Tasks:
|
||
|
|
|
||
|
|
1. finalize crisis keyword and pattern sets
|
||
|
|
2. validate crisis response templates and regional resources
|
||
|
|
3. add safety dashboards and alerting
|
||
|
|
4. add audit trail for safety decisions
|
||
|
|
|
||
|
|
Validation goals:
|
||
|
|
|
||
|
|
- crisis path returns under 1 second in most cases
|
||
|
|
- no crisis path returns reframing output
|
||
|
|
|
||
|
|
## 3.2 Billing and Entitlements
|
||
|
|
|
||
|
|
Tasks:
|
||
|
|
|
||
|
|
1. complete App Store Server Notifications ingestion
|
||
|
|
2. complete Google Play RTDN ingestion
|
||
|
|
3. build reconciliation jobs for both stores (entitlements sync)
|
||
|
|
4. test expired, canceled, trial, billing retry, and restore scenarios
|
||
|
|
5. add paywall gating in all required clients
|
||
|
|
|
||
|
|
Validation goals:
|
||
|
|
|
||
|
|
- entitlement state converges within minutes after billing changes
|
||
|
|
- no premium endpoint access for expired plans
|
||
|
|
|
||
|
|
## 3.3 Reliability Engineering
|
||
|
|
|
||
|
|
Tasks:
|
||
|
|
|
||
|
|
1. finalize health checks and readiness probes
|
||
|
|
2. add backup and restore procedures for Postgres
|
||
|
|
3. add Redis persistence strategy for critical counters if required
|
||
|
|
4. define incident severity levels and on-call workflow
|
||
|
|
|
||
|
|
Validation goals:
|
||
|
|
|
||
|
|
- verified DB restore from backup in staging
|
||
|
|
- runbook exists for API outage, DB outage, AI provider outage
|
||
|
|
|
||
|
|
## 3.4 Security and Compliance Baseline
|
||
|
|
|
||
|
|
Tasks:
|
||
|
|
|
||
|
|
1. secrets rotation policy and documented process
|
||
|
|
2. verify transport security and secure headers
|
||
|
|
3. verify account deletion and data export flows
|
||
|
|
4. prepare privacy policy and terms for submission
|
||
|
|
|
||
|
|
Validation goals:
|
||
|
|
|
||
|
|
- basic security checklist signed off
|
||
|
|
- app store privacy disclosures map to real data flows
|
||
|
|
|
||
|
|
## 3.5 Observability and Cost Control
|
||
|
|
|
||
|
|
Tasks:
|
||
|
|
|
||
|
|
1. define alerts for latency, error rate, and AI spend thresholds
|
||
|
|
2. implement monthly spend cap and automatic degradation rules
|
||
|
|
3. monitor feature-level token cost dashboards
|
||
|
|
|
||
|
|
Validation goals:
|
||
|
|
|
||
|
|
- alert thresholds tested in staging
|
||
|
|
- degradation path verified (Lens fallback first)
|
||
|
|
|
||
|
|
## 3.6 Beta and Release Pipeline
|
||
|
|
|
||
|
|
Tasks:
|
||
|
|
|
||
|
|
1. set up TestFlight internal/external testing
|
||
|
|
2. set up Android internal testing track
|
||
|
|
3. run beta cycle with scripted feedback collection
|
||
|
|
4. triage and fix launch-blocking defects
|
||
|
|
|
||
|
|
Validation goals:
|
||
|
|
|
||
|
|
- no unresolved launch-blocking defects
|
||
|
|
- release checklist complete for both stores
|
||
|
|
|
||
|
|
## 4. Suggested Execution Plan
|
||
|
|
|
||
|
|
Week 1:
|
||
|
|
|
||
|
|
- safety hardening and billing reconciliation
|
||
|
|
- initial reliability runbooks
|
||
|
|
|
||
|
|
Week 2:
|
||
|
|
|
||
|
|
- security/compliance checks
|
||
|
|
- backup and restore drills
|
||
|
|
- full observability alert tuning
|
||
|
|
|
||
|
|
Week 3:
|
||
|
|
|
||
|
|
- TestFlight and Play internal beta
|
||
|
|
- defect triage and fixes
|
||
|
|
|
||
|
|
Week 4 (if needed):
|
||
|
|
|
||
|
|
- final store submission materials
|
||
|
|
- go/no-go readiness review
|
||
|
|
|
||
|
|
## 5. Release Checklists
|
||
|
|
|
||
|
|
## 5.1 API release checklist
|
||
|
|
|
||
|
|
- migration plan reviewed
|
||
|
|
- rollback plan documented
|
||
|
|
- dashboards green
|
||
|
|
- error budget acceptable
|
||
|
|
|
||
|
|
## 5.2 Mobile release checklist
|
||
|
|
|
||
|
|
- build reproducibility verified
|
||
|
|
- crash-free session baseline from beta acceptable
|
||
|
|
- paywall and entitlement states correct
|
||
|
|
- copy and metadata final
|
||
|
|
|
||
|
|
## 5.3 Business and policy checklist
|
||
|
|
|
||
|
|
- privacy policy URL live
|
||
|
|
- terms URL live
|
||
|
|
- support contact available
|
||
|
|
- crisis resources configured for launch regions
|
||
|
|
|
||
|
|
## 6. Exit Criteria
|
||
|
|
|
||
|
|
You can exit Phase 3 when:
|
||
|
|
|
||
|
|
- app is store-ready with stable entitlement behavior
|
||
|
|
- safety flow is verified and monitored
|
||
|
|
- operations runbooks and alerts are live
|
||
|
|
- backup and restore are proven in practice
|
||
|
|
|
||
|
|
## 7. Risks To Watch
|
||
|
|
|
||
|
|
- Risk: entitlement mismatch from webhook delays.
|
||
|
|
- Mitigation: scheduled reconciliation and idempotent webhook handling.
|
||
|
|
- Risk: launch-day AI latency spikes.
|
||
|
|
- Mitigation: timeout limits and graceful fallback behavior.
|
||
|
|
- Risk: compliance gaps discovered late.
|
||
|
|
- Mitigation: complete privacy mapping before store submission.
|