v19.0: Launch Preparation

Status: All Documentation Complete ✅ - Awaiting User Execution Priority: HIGH Documentation Effort: ~15 hours (complete) User Execution Effort: ~20-25 hours over 5+ weeks Dependencies: v18.0 complete ✅

📋 USER ACTION REQUIRED

All planning and documentation is complete. You now need to execute the procedures.

👉 START HERE: v19.0 User Execution Guide

This execution guide provides a clear, step-by-step walkthrough of exactly what you need to do, with time estimates, checklists, and document references.

Quick Overview:

1. Phase 1: Final QA (4-6 hours one-time) - Manual testing
2. Beta Testing (4 weeks, 15-20 min/day) - Controlled rollout
3. Full Launch (After beta passes) - Public availability

Executive Summary

v19.0 focuses on final preparations for public launch of CareConnect. All technical infrastructure is complete (v18.0); this phase ensures the platform is ready for real users through final quality checks, user-facing documentation, launch monitoring, and soft-launch procedures.

Goal: Safely transition from development to production with minimal risk and maximum user readiness.

Status: All documentation complete. Ready for user-led execution.

Context

Current State (v18.0 Complete):

• ✅ Production-ready technical infrastructure
• ✅ 100% circuit breaker protection
• ✅ Full observability and alerting
• ✅ SLO monitoring (PROVISIONAL targets)
• ✅ 713 passing tests
• ✅ Zero security vulnerabilities
• ✅ WCAG 2.1 AA compliant
• ✅ 7-language support
• ✅ Offline-ready PWA

What's Missing for Launch:

• User-facing documentation (how-to guides, FAQ)
• Launch monitoring and rollback procedures
• Final data quality review
• Production environment configuration verification
• Launch communication materials (optional)
• Soft-launch beta testing plan

Implementation Phases

Phase 1: Final Quality Assurance (4-6 hours)

Goal: Ensure all critical functionality works flawlessly for real users.

Task 1.1: Production Environment Audit (2h)

Deliverables:

• [ ] Verify all environment variables in production match .env.example
• [ ] Confirm Supabase RLS policies are active
• [ ] Test auth flows (signup, login, password reset) in production
• [ ] Verify CSP headers are enforcing correctly
• [ ] Check CORS configuration for API routes
• [ ] Confirm rate limiting is active (60 req/min)
• [ ] Test error boundary fallbacks

Verification Script:

# Run in production environment
npm run verify:production

Acceptance Criteria:

• All environment variables documented and set
• Auth flows work without errors
• Security headers present in all responses
• Rate limiting triggers correctly

Task 1.2: Critical User Journey Testing (2-3h)

Goal: Manually test the 5 most important user flows.

Test Scenarios:

1. Crisis Search (Top Priority)
2. User searches "suicide help"
3. Crisis banner appears
4. Distress Centre Kingston appears first
5. Contact information is accurate and clickable

6. Expected time: <5 seconds total

7. General Search Flow

8. User searches "food bank"
9. Results appear in <800ms
10. Top 3 results are relevant
11. Service cards display complete information

12. Map shows correct locations

13. Accessibility Navigation

14. Complete search using only keyboard
15. Screen reader announces results correctly
16. Focus indicators visible throughout

17. No keyboard traps

18. Mobile Experience

19. Search works on mobile device
20. Map is usable with touch
21. Contact buttons work (tel: links)

22. Service cards readable at mobile width

23. Offline Mode

24. Disconnect network
25. Search still works
26. Results returned from cache
27. Offline indicator shows
28. Network reconnection syncs properly

Acceptance Criteria:

• All 5 scenarios complete without errors
• Performance meets targets (<800ms p95)
• Accessibility checklist 100% passed
• Mobile usability confirmed

Task 1.3: Data Quality Final Review (1h)

Goal: Ensure critical services have complete, accurate data.

Audit Checklist:

• [ ] Run npm run audit:data and review gaps
• [ ] Verify top 20 most-searched services have:
• ✅ Complete contact information
• ✅ Accurate hours (or "Call for hours")
• ✅ Geocoded coordinates
• ✅ French translations (name, description)
• ✅ Clear access_script
• [ ] Spot-check 5 random services for data accuracy
• [ ] Verify crisis services (suicide, domestic violence) are L2+ verified

Priority Services to Verify:

1. Distress Centre Kingston (crisis)
2. Kingston Community Health Centre (primary care)
3. Partners in Mission Food Bank (food security)
4. Kingston Youth Shelter (housing)
5. Interval House (domestic violence)

Acceptance Criteria:

• Top 20 services have complete data
• All crisis services verified and accurate
• No placeholder text in production data

Phase 2: User-Facing Documentation (4-6 hours)

Goal: Help users understand how to use the platform effectively.

Task 2.1: User Guide (2-3h)

Create: docs/user-guide.md (public-facing)

Sections:

1. Getting Started
2. What is CareConnect?
3. Who is this for?

4. How to search effectively

5. Search Tips

6. Using keywords vs. categories
7. Understanding verification levels (L1, L2, L3)
8. Filtering by hours (open now)

9. Using proximity search

10. Understanding Results

11. Service card information
12. Contact methods (phone, email, website, in-person)
13. Access scripts (eligibility, documents needed)

14. Hours of operation

15. Accessibility Features

16. Keyboard navigation shortcuts
17. Screen reader support
18. Language selection

19. Offline mode

20. Privacy & Data

21. No tracking or logging
22. On-device search (local mode)
23. Open source and transparent

Format: Simple markdown, clear headings, screenshots optional

Acceptance Criteria:

• User guide covers all 5 sections
• Written at 8th grade reading level
• Available in English and French
• Linked from footer

Task 2.2: FAQ (1-2h)

Create: docs/faq.md (public-facing)

Questions to Cover:

General:

• What is CareConnect?
• Is this an official government service?
• How do I report incorrect information?
• How often is data updated?

Privacy:

• Do you track my searches?
• Is my data shared with anyone?
• Can service providers see who searches for them?

Data:

• How do you verify services?
• Why isn't [specific service] listed?
• How can I add a service?
• What do verification levels mean?

Technical:

• Why does it work offline?
• Which browsers are supported?
• Is there a mobile app?
• What if I have accessibility needs?

Acceptance Criteria:

• At least 12 questions answered
• Clear, honest, non-technical language
• Linked from footer
• Bilingual (EN/FR)

Task 2.3: Error Messages & Help Text (1h)

Goal: Improve in-app messaging for better UX.

Audit & Improve:

• [ ] Review all user-facing error messages
• [ ] Ensure errors are actionable ("Try X" instead of "Error Y")
• [ ] Add helpful hints to search box
• [ ] Improve "No results found" messaging
• [ ] Add clear calls-to-action on empty states

Example Improvements:

Before:

Error: No services found

After:

No results for "foo bar"

Try:
• Using different keywords (e.g., "food assistance" instead of "food stamps")
• Browsing categories below
• Checking spelling

Acceptance Criteria:

• All error messages reviewed and improved
• User testing confirms clarity
• Messages are encouraging, not blaming

Phase 3: Launch Monitoring & Safety (3-5 hours)

Goal: Monitor launch closely and have clear rollback procedures.

Task 3.1: Launch Monitoring Checklist (1-2h)

Create: docs/operations/launch-monitoring-checklist.md

Pre-Launch (T-1 hour):

• [ ] Verify production deployment successful
• [ ] Confirm health check returns 200 OK
• [ ] Test critical user journey (crisis search)
• [ ] Verify SLO dashboard showing green
• [ ] Check Slack alerts are enabled
• [ ] Confirm Axiom metrics flowing
• [ ] Review error logs (should be empty)

Launch Day (First 4 hours):

• [ ] Monitor /admin/observability dashboard every 30 minutes
• [ ] Check Slack for any alerts
• [ ] Review top 10 search queries (privacy-safe, aggregate only)
• [ ] Watch error rate (<0.5% target)
• [ ] Monitor p95 latency (<800ms target)
• [ ] Verify circuit breaker stays CLOSED
• [ ] Check no unexpected 5xx errors

Launch Day (Hours 4-24):

• [ ] Monitor observability dashboard every 2 hours
• [ ] Review Axiom metrics trends
• [ ] Check for any user-reported issues
• [ ] Verify SLO compliance remains green
• [ ] Review search quality (are users finding what they need?)

Day 2-7 (Post-Launch Week):

• [ ] Daily dashboard check
• [ ] Review SLO compliance summary
• [ ] Analyze search patterns for improvements
• [ ] Monitor for any data quality issues
• [ ] Check for any accessibility reports

Acceptance Criteria:

• Checklist covers pre-launch, launch day, and week 1
• Clear escalation procedures if issues arise
• Monitoring duties assigned (if team)

Task 3.2: Rollback Procedures (1-2h)

Create: docs/operations/launch-rollback-procedures.md

Scenarios & Procedures:

Scenario 1: Critical Bug Discovered (SEV-1)

Symptoms: Search broken, auth failing, data loss risk

Rollback Procedure:

1. Immediately revert to previous deployment via Vercel dashboard (<2 minutes)
2. Post incident notice on status page (if configured)
3. Notify stakeholders via Slack
4. Document bug in GitHub issue
5. Create hotfix branch, test thoroughly
6. Re-deploy with fix

Time to Rollback: <5 minutes

Scenario 2: High Error Rate (SEV-2)

Symptoms: Error rate >5% sustained, users reporting issues

Mitigation Procedure:

1. Check observability dashboard for error patterns
2. Review recent deployment changes
3. If deployment-related: rollback (see above)
4. If data-related: disable affected feature via feature flag
5. Investigate root cause
6. Deploy fix or data correction

Time to Mitigate: <15 minutes

Scenario 3: Performance Degradation (SEV-3)

Symptoms: p95 latency >1500ms, users reporting slowness

Mitigation Procedure:

1. Check circuit breaker state (if OPEN, database issue)
2. Review database connection pool
3. Check for slow queries in Supabase dashboard
4. If persistent: enable aggressive caching
5. Investigate and optimize queries
6. Deploy performance fix

Time to Mitigate: <1 hour

Acceptance Criteria:

• Rollback procedures documented for 3 severity levels
• Clear decision tree (when to rollback vs. forward-fix)
• Time estimates realistic
• Tested in staging environment

Task 3.3: Communication Templates (1h)

Goal: Pre-written messages for common scenarios.

Templates to Create:

1. Launch Announcement (internal)
2. Incident Notice (if major issue during launch)
3. Status Update (for ongoing incidents)
4. All-Clear (issue resolved)
5. Weekly Summary (post-launch metrics)

Example: Launch Announcement (Internal)

🚀 CareConnect: LIVE

The platform is now publicly accessible at https://careconnect.ing

Current Status:
✅ All systems operational
✅ SLO compliance: Green
✅ Circuit breaker: CLOSED
✅ Error rate: <0.1%

Monitoring Plan:
• Hourly checks (first 4 hours)
• Dashboard: /admin/observability
• Slack alerts: Enabled

Escalation: [On-call engineer contact]

Next Update: In 2 hours

Acceptance Criteria:

• 5 communication templates created
• Clear, professional tone
• Fill-in-the-blank sections marked

Phase 4: Soft Launch Strategy (3-5 hours)

Goal: Launch to small group first, gather feedback, iterate.

Task 4.1: Beta Testing Plan (2-3h)

Soft Launch Approach:

Week 1: Invite-Only Beta (10-20 users)

• Invite trusted community partners
• Provide user guide and FAQ
• Ask for specific feedback:
• Is search finding what you need?
• Any confusing UI elements?
• Mobile experience acceptable?
• Accessibility issues?

Week 2: Expanded Beta (50-100 users)

• Invite broader community (social workers, librarians)
• Monitor error rates and SLO compliance
• Review top search queries
• Adjust data or rankings based on feedback

Week 3-4: Public Soft Launch

• Announce publicly but low-key (no press release)
• Monitor closely for issues
• Iterate based on real usage patterns
• Prepare for full public launch

Feedback Collection:

• Simple feedback form on site
• Email: feedback@careconnect.ing
• GitHub issues (for tech-savvy users)
• Informal conversations with beta users

Acceptance Criteria:

• Beta testing plan covers 3 phases (invite, expanded, public soft)
• Feedback mechanisms in place
• Success criteria defined (e.g., >80% users find what they need)

Task 4.2: Beta Feedback Analysis (1-2h)

Goal: Systematically review and act on beta feedback.

Process:

1. Collect Feedback (ongoing during beta)
2. Categorize: Bug, Enhancement, Data Quality, UX, Other

3. Priority: P0 (blocking), P1 (important), P2 (nice-to-have)

4. Weekly Review (1 hour/week during beta)

5. Review all feedback with team
6. Create GitHub issues for bugs
7. Document enhancement requests

8. Prioritize fixes

9. Act on Critical Issues

10. P0 bugs: Fix immediately (<24 hours)
11. P1 enhancements: Fix before full launch

12. P2 enhancements: Backlog for post-launch

13. Communicate Back

14. Thank users for feedback
15. Notify when issues are fixed
16. Build trust and engagement

Acceptance Criteria:

• Feedback collection system operational
• Weekly review process established
• All P0/P1 issues addressed before full launch

Phase 5: Optional Launch Materials (2-3 hours)

Goal: Professional launch communications (optional, not required for launch).

Task 5.1: Press Kit (1-2h)

Optional Deliverables:

• One-page platform summary (PDF)
• Screenshots (desktop, mobile)
• Logo assets (SVG, PNG)
• Founder/team bios
• Contact information for media

Use Case: If approached by local media or community organizations

Task 5.2: Social Media Assets (1h)

Optional Deliverables:

• Launch announcement graphics
• Social media copy templates
• Hashtags: #KingstonON #SocialServices #CivicTech
• Sample posts for Twitter, Facebook, LinkedIn

Use Case: If planning social media presence

Success Criteria

Phase 1: Final QA ✅

• [x] QA procedures documented - docs/operations/final-qa-procedures.md
• [ ] Production environment audit 100% passed - PENDING USER EXECUTION
• [ ] All 5 critical user journeys tested successfully - PENDING USER EXECUTION
• [ ] Top 20 services have complete, accurate data - PENDING USER EXECUTION
• [ ] Zero critical bugs in staging - PENDING USER EXECUTION

Phase 2: Documentation ✅

• [x] User guide published (EN + FR) - docs/user-guide.md + docs/user-guide.fr.md
• [x] FAQ with at least 12 questions (22 questions total) - docs/faq.md + docs/faq.fr.md
• [x] All error messages reviewed and improved - messages/en.json + messages/fr.json
• [x] Documentation linked from site footer - /user-guide and /faq routes created

Phase 3: Launch Safety ✅

• [x] Launch monitoring checklist created - docs/operations/launch-monitoring-checklist.md
• [x] Rollback procedures documented and tested - docs/operations/launch-rollback-procedures.md
• [x] Communication templates ready (5 templates) - docs/operations/communication-templates.md
• [ ] On-call schedule established (if team) - PENDING USER ACTION

Phase 4: Soft Launch ✅

• [x] Beta testing plan documented - docs/operations/beta-testing-plan.md
• [x] Feedback collection system operational - docs/operations/beta-feedback-analysis.md
• [ ] Week 1 beta completed with <5 P0 bugs - PENDING USER EXECUTION
• [ ] Week 2 expanded beta completed with <10 P1 bugs - PENDING USER EXECUTION
• [ ] Ready for public launch - PENDING USER EXECUTION

Phase 5: Optional ✅

• [ ] Press kit available (if desired)
• [ ] Social media assets ready (if desired)

Timeline

Recommended Schedule:

• Week 1: Phase 1 (QA) + Phase 2 (Documentation)
• Week 2: Phase 3 (Launch Safety) + Phase 4 (Beta Planning)
• Week 3-4: Soft Launch Beta (Phase 4 execution)
• Week 5: Address beta feedback, prepare for full launch
• Week 6: Full public launch 🚀

Total Duration: 5-6 weeks from start to full launch

Dependencies & Blockers

Prerequisites (All Complete ✅):

• ✅ v18.0 Production Observability complete
• ✅ Zero security vulnerabilities
• ✅ All tests passing (713 tests)
• ✅ Circuit breaker protection active
• ✅ SLO monitoring operational

External Dependencies:

• User availability for beta testing (coordinate with community partners)
• Domain configuration for status page (optional, deferred)
• Slack workspace for alerts (recommended, not required)

No Blockers: This phase can begin immediately.

Risk Assessment

High Risk Items

1. Data Quality Issues Discovered During Beta
2. Mitigation: Thorough data audit in Phase 1

3. Fallback: Disable problematic services temporarily

4. Unexpected Traffic Spike

5. Mitigation: Circuit breaker + rate limiting already active

6. Fallback: Vercel auto-scales; monitor closely

7. Critical Bug in Production

8. Mitigation: Comprehensive testing in Phase 1
9. Fallback: <5 minute rollback procedure documented

Medium Risk Items

1. Poor Beta User Feedback
2. Mitigation: Soft launch allows iteration before full launch

3. Fallback: Extend beta period, address concerns

4. Performance Issues Under Real Load

5. Mitigation: Load testing already done, SLO monitoring active
6. Fallback: Query optimization, caching improvements

Low Risk Items

1. User Confusion About Features
2. Mitigation: User guide and FAQ address common questions
3. Fallback: Improve documentation based on feedback

Effort Breakdown

P0 Tasks (Required for Launch): 12-16 hours P1 Tasks (Highly Recommended): 2-4 hours P2 Tasks (Optional): 2-3 hours

Out of Scope

Not Included in v19.0:

• Major feature development (defer to v20.0+)
• Mobile app launch (still blocked on macOS/accounts)
• Upptime status page (blocked on domain config)
• L3 partnership establishment (ongoing, separate from launch)
• Advanced analytics or user tracking (privacy-first approach)
• Marketing campaigns or paid advertising

Related Documentation

• v18.0 Implementation Summary
• Production Deployment Checklist
• Incident Response Plan
• Operational Runbooks
• Roadmap

Next Steps

1. Review this plan with stakeholders
2. Prioritize phases based on launch timeline
3. Assign tasks (if team) or create implementation schedule (if solo)
4. Begin Phase 1 (Final QA) immediately
5. Track progress using GitHub issues or task list

Created: 2026-02-09 Status: Planning (Awaiting User Approval) Next Review: After user feedback on plan