Payday — Production Readiness Checklist

Purpose: Verify that every feature, system, and integration is fully working before opening Payday to real paying members. This checklist is the single source of truth.

How to use:

• Work top to bottom
• Every item must be checked ✅ or explicitly waived with a reason documented
• A waived item must have a follow-up date set
• This document must be signed off by the lead engineer before go-live

Last reviewed: _______________
Signed off by: _______________
Go-live date: _______________

#SECTION 1 — Infrastructure & Docker

##1.1 Containers

• All 6 containers start cleanly from fresh: docker compose down -v && docker compose up -d
• payday-api container is running and healthy
• payday-postgres container is running and healthy (pgvector/pgvector:pg16 image)
• payday-redis container is running and healthy
• payday-nginx container is running and healthy
• payday-mailhog container replaced with real SMTP in production (mailhog removed)
• payday-portainer secured with strong password or removed from production
• All containers set to restart: always in production compose file
• No dev-only volume mounts (.:/app) in production image
• Production Dockerfile uses target: production (not development)

##1.2 Networking

• All containers on payday-network bridge (172.20.0.0/24)
• PostgreSQL port 5432 NOT exposed to public in production
• Redis port 6379 NOT exposed to public in production
• Only ports 80 and 443 exposed via Nginx
• UFW firewall active: only 22, 80, 443 open (+ 1935 if streaming)
• Docker socket not mounted in API container

##1.3 SSL / HTTPS

• SSL certificate obtained (Let's Encrypt via Certbot or equivalent)
• Certificate covers api.yourdomain.com
• HTTPS enforced — HTTP redirects to HTTPS (301)
• SSL certificate auto-renewal configured (cron job)
• Strict-Transport-Security header present in Nginx config
• Certificate expiry monitored (UptimeRobot or equivalent)

##1.4 Nginx

• Production Nginx config (nginx.prod.conf) active (not dev config)
• Rate limiting zones active: 100 req/min general, 10 req/min auth
• WebSocket proxying working (/socket.io/ with Upgrade headers)
• /uploads/ static file serving working
• gzip compression enabled
• Security headers set: X-Frame-Options, X-Content-Type-Options, X-XSS-Protection

##1.5 Server & Backups

• Server sized appropriately: minimum 2 vCPU / 4 GB RAM for launch
• Disk space: minimum 80 GB SSD
• Database backup script (ci/db-backup.sh) tested and running on cron
• Backup retention: 30 days minimum
• Backup restore validated: ran ci/db-restore-validate.sh on a backup file — all checks pass
• Backup files stored off-server (S3 or equivalent)
• Log rotation configured on all containers (max-size, max-file limits)

#SECTION 2 — Database

##2.1 Schema

• All 23 tables created (run \dt in psql — verify full list)
• pgvector extension loaded: SELECT * FROM pg_extension WHERE extname='vector'
• pg_trgm extension loaded
• uuid-ossp extension loaded
• All enums created (auth_provider_enum, membership_tier_enum, etc.)
• All indexes created (run \di — check against 05_Indexes_and_Performance.sql)
• IVFFlat index on member_profiles.embedding exists
• All triggers active (\dT+ in psql — verify set_updated_at, recalculate_reputation, etc.)
• All 12 default channels seeded

##2.2 Data Integrity

• Reputation trigger tested: INSERT into reputation_events → member_profiles.reputation_score updates automatically
• Comment count trigger tested: create comment → parent post comment_count increments
• Resource rating trigger tested: add rating → resources.avg_rating recalculates
• Soft delete working: deleted posts have deleted_at set, not hard-deleted
• Foreign key constraints in place (test by attempting to insert orphan records)

##2.3 Performance

• log_min_duration_statement=500 configured (slow query logging)
• Connection pool: DB_POOL_MAX=20 confirmed
• Test home feed query under load — responds under 50ms
• Test member discovery query with filters — responds under 80ms
• No DB_SYNC=true in production

##2.4 Seed Data

• All @example.com test users removed from production database
• Admin account created with a strong password (not the default seed)
• Default channels present and active
• No lorem ipsum content visible to real users

#SECTION 3 — Authentication & Authorization

##3.1 JWT

• JWT_ACCESS_SECRET is 64+ characters, randomly generated
• JWT_REFRESH_SECRET is 64+ characters, different from access secret
• Access token expires in 15 minutes
• Refresh token expires in 30 days
• Refresh token rotation working: old token invalid after refresh
• Max 5 refresh tokens per user (multi-device)
• All tokens revoked on logout-all

##3.2 Registration & Login

• Registration creates users record + member_profiles record
• Slug auto-generated and unique
• Welcome email queued and delivered (check SMTP logs)
• Email verification token sent
• Email verification link works and sets email_verified = true
• Login returns access + refresh tokens
• Login fails with wrong password (401)
• Account lock: 5 failed attempts → locked 15 minutes → correct message shown
• Account lock resets after successful login

##3.3 Password Reset

• Forgot password sends reset email (check SMTP logs)
• Reset token expires (configurable, default 1 hour)
• Password reset link works and updates password hash
• Old tokens invalidated after password reset
• Weak passwords rejected (min 8 chars, uppercase, number, special char)

##3.4 Google OAuth

• GOOGLE_CLIENT_ID and GOOGLE_CLIENT_SECRET set in production .env
• Redirect URI registered in Google Cloud Console: https://api.yourdomain.com/api/v1/auth/google/callback
• Google login flow completes end-to-end
• New Google user: users + member_profiles created automatically
• Returning Google user: existing account found by provider_id
• Google user can update their profile (no password required)

##3.5 Apple Sign-In

• APPLE_CLIENT_ID, APPLE_TEAM_ID, APPLE_KEY_ID, APPLE_PRIVATE_KEY set in .env
• Service ID registered in Apple Developer Console
• Redirect URI registered: https://api.yourdomain.com/api/v1/auth/apple/callback
• Apple requires HTTPS — SSL certificate confirmed
• Apple login flow completes end-to-end
• Apple user's name stored on first login (Apple only sends name once)
• Returning Apple user: existing account found by provider_id

##3.6 Guards & Role Enforcement

• @Public() endpoints work without JWT
• Protected endpoints return 401 without valid JWT
• Expired access token returns 401
• Admin routes return 403 for non-admin users
• Moderator routes return 403 for regular members
• @RequireTier('pro') routes return 403 for Starter users
• @RequireTier('elite') routes return 403 for Pro users
• Elite features (Deal Rooms) return 403 for Starter/Pro users

#SECTION 4 — Member Profiles & Discovery

##4.1 Profiles

• Profile creation works on registration
• All profile fields updatable via PATCH /members/me
• Avatar upload works (multipart form, max size enforced)
• Cover photo upload works
• Avatar processed by media:process-image BullMQ job (resized to 400x400)
• Slug generation: unique, URL-safe, auto-increments on collision
• Profile view count increments on GET /members/:id
• Verified badge visible on verified profiles
• Availability status badge visible in directory
• Social links stored and returned correctly

##4.2 Connections

• Connection request sends notification to addressee
• Connection accepted/rejected updates status correctly
• Accepted connection: both users appear in each other's connections list
• Blocked user: cannot send messages, connection requests, or see profile
• Connection count visible on profile
• PATCH /members/connections/:id with status: accepted works

##4.3 Member Discovery

• Directory loads with default sorting (reputation DESC)
• Filter by niche works
• Filter by skills (array overlap) works
• Filter by revenue stage works
• Filter by availability works
• Filter by isVerified works
• Full-text search on name + tagline + bio works
• Pagination works (page 1, page 2, etc.)
• Response time under 80ms on filtered queries

##4.4 AI Match Suggestions

• OPENAI_API_KEY set in production .env (or fallback mode confirmed working)
• Embedding generated for new member on profile create/update
• embeddings:generate BullMQ job processes successfully
• pgvector IVFFlat index active on member_profiles.embedding
• GET /members/suggested returns 10 members ranked by similarity
• Results exclude: self, already connected, blocked users, inactive users
• Results cached in Redis at matches:{userId} for 24 hours
• Cache invalidated on profile update
• Weekly embeddings:refresh-all cron job scheduled and tested
• Fallback (no OpenAI key): skill-overlap suggestions returned instead of error

##4.5 Leaderboard

• GET /members/leaderboard returns top 20 by reputation
• Week and month filters work
• Results cached in Redis leaderboard:all / leaderboard:week for 1 hour
• Leaderboard updates when reputation events are inserted

#SECTION 5 — Community Feed

##5.1 Channels

• All 12 default channels present (General, Wins, Paid Ads, E-commerce, Agency Life, Copywriting, Investing, Hiring, Tech & Tools, Mindset, Deal Room, Introductions)
• GET /feed/channels returns active channels
• Posts can be created in a specific channel
• Posts without channelId appear in main feed

##5.2 Posts

• Text post creates and appears in feed
• Image post: file upload works, media_urls stored
• Video post: upload works, duration validated
• Link post: link_preview data populated
• Poll post: poll_data stored correctly
• Document post: PDF upload works
• Posts appear in home feed for connections
• Posts appear in channel feed for channel members
• Announcements (is_announcement: true) appear for all members
• Post edit works within 30-minute window, blocked after
• Soft delete: deleted_at set, post hidden from feed
• view_count increments on post view
• Pinned posts appear at top of feed (admin only)

##5.3 Comments & Reactions

• Comment creates as post with parent_id set
• comment_count on parent post increments (trigger)
• Threaded replies (comment on comment) work
• All 6 reaction types work: fire, rocket, clap, money, heart, lightbulb
• Reacting twice with same type = toggle off (idempotent)
• reaction_counts JSONB updated correctly on react/unreact
• Real-time post_reacted Socket.io event emitted after reaction
• Reaction count visible in feed without page reload

##5.4 Saved Posts

• POST /feed/posts/:id/save toggles save (save + unsave)
• GET /feed/saved returns user's saved posts
• Saved post still visible even if author is no longer a connection

#SECTION 6 — Direct Messaging & Deal Rooms

##6.1 Conversations

• 1:1 DM creates conversation between two users
• Creating DM with existing conversation partner returns existing conversation (no duplicates)
• Group chat creation works with 2+ participants
• Group chat name and avatar settable
• Deal Room creation works (Elite tier only — tested with Pro → 403)
• Inbox ordered by last_message_at DESC
• unread_count visible per conversation in inbox

##6.2 Messages

• Text message sends and appears for both participants
• File upload sends: image, PDF, spreadsheet (multipart, 50MB limit enforced)
• File type restrictions enforced (no .php, .exe, .sh, etc.)
• Reply-to (quoted message) works — reply_to_id stored
• Message soft-delete: deleted message shows "Message deleted"
• Read receipts: read_by array updated when recipient views
• last_message_preview updated on conversation after send
• Message history loads newest-first with cursor pagination

##6.3 Real-Time Messaging (Socket.io)

• new_message event received instantly by all conversation participants
• typing_start event broadcasts to other participants
• typing_stop event broadcasts (or auto-stops after 5s)
• message_read event fires when recipient opens conversation
• Client joins conversation:{id} room after opening conversation
• Messages delivered to offline user via push notification (queued)
• Socket.io connection authenticated via JWT on handshake
• Invalid JWT on handshake → socket disconnected immediately
• Redis adapter active for multi-instance pub/sub (DB 4)

#SECTION 7 — Opportunities Board

##7.1 Posting Opportunities

• All 5 opportunity types work: full_time, freelance, partnership, revenue_share, jv
• Starter tier → 403 on POST /opportunities (Pro+ required)
• Compensation JSONB stores correctly for each type
• skills_required array stores and filters correctly
• Expiry date sets expires_at, cleanup job expires at midnight
• opportunity_count increments on member_profiles for poster
• Opportunity visible in directory immediately after posting

##7.2 Applications

• Application creates with cover_letter and portfolio_urls
• Duplicate application returns 409 Conflict
• Closed/expired/filled opportunity returns 400 on apply
• Poster receives in-app notification on new application
• Poster can view all applications for their listing
• Application status updates work: reviewing, accepted, rejected
• Applicant notified when status changes
• Applicant can view all their submitted applications

##7.3 Cleanup

• cleanup:expire-opportunities cron runs daily at 2am
• Expired opportunities show status: expired in listings
• Expired opportunities excluded from default GET /opportunities response

#SECTION 8 — Events & Masterminds

##8.1 Event Creation

• All event types work: virtual, in_person, hybrid, mastermind, webinar
• Starter tier → 403 on POST /events (Pro+ required)
• max_attendees enforced (RSVP blocked when full)
• Free events (is_free: true) work without Stripe
• Paid events (is_free: false) require Stripe checkout (implementation TBD)
• Timezone stored and returned correctly
• Stream key auto-generated on event creation (UUID, stored as events.stream_key)

##8.2 RSVPs & Notifications

• RSVP creates event_attendees record
• RSVP increments events.attendee_count
• Second RSVP call cancels RSVP (toggle)
• RSVP confirmation email queued and sent
• Event reminder notification queued for 1 hour before starts_at
• Reminder delivered via: in-app notification + email

##8.3 Live Streaming (RTMP)

• tiangolo/nginx-rtmp container added to production docker-compose.yml
• Port 1935 (RTMP ingest) open in firewall
• OBS/Streamyard can connect to rtmp://yourdomain.com:1935/live/{streamKey}
• Stream key verification endpoint working: POST /events/verify-stream-key
• Invalid stream key rejected (403) — no unauthorized streams accepted
• HLS output available: http://yourdomain.com:8080/hls/{streamKey}/index.m3u8
• PATCH /events/:id/go-live sets status to live and emits event_started Socket.io event
• event_started event received by all RSVPed attendees in event:{eventId} room
• Stream URL included in event_started payload
• Live event chat: attendees can send messages via send_event_chat Socket.io event
• event_chat event broadcast to all room members
• viewer_count emitted every 30 seconds to event room

##8.4 Event Completion & Recording

• PATCH /events/:id/complete sets status to completed
• recording_url stored when provided
• All RSVPed attendees notified when recording is available
• media:combine-hls BullMQ job merges HLS segments → MP4 (if self-hosted recording)
• Replay available at events.recording_url in event detail

##8.5 Cleanup

• cleanup:archive-events cron runs daily at 2am
• Events past ends_at automatically set to completed if still live

#SECTION 9 — Resource Library

##9.1 Uploads & Approval

• All 8 resource types work: template, sop, course, playbook, swipe_file, script, tool, other
• Starter tier → 403 on POST /resources (Pro+ required)
• File upload stores in uploads/resources/
• New resource has is_approved: false — NOT visible in library until admin approves
• Admin can approve resource via admin dashboard
• Approved resource appears in library

##9.2 Discovery & Ratings

• Library filterable by: type, niche, skill_level, tags, is_free
• Full-text search works on title + description
• Download count increments on resource download
• Rating submission: 1–5 stars + optional review text
• Duplicate rating returns 409 (one rating per user per resource)
• resources.avg_rating and rating_count auto-updated by trigger

#SECTION 10 — Reputation & Leaderboard

##10.1 Reputation Events

• profile_complete (+50): fires when onboarding_completed set to true
• first_post (+25): fires on first post creation
• post_got_10_reactions (+100): fires when reaction_counts total reaches 10
• post_got_50_reactions (+250): fires at 50 reactions
• connection_made (+20): fires when connection accepted
• opportunity_posted (+75): fires on opportunity creation
• opportunity_filled (+150): fires when opportunity status set to filled
• event_hosted (+200): fires when event marked completed
• resource_uploaded (+50): fires on resource upload
• member_referred (+100): fires when referred user activates
• content_removed (-50): fires on moderation removal action
• All events append-only (no UPDATE or DELETE on reputation_events)
• member_profiles.reputation_score auto-updates via PostgreSQL trigger

##10.2 Badges

• Badge assignment works via admin dashboard
• Badges visible on member profiles
• Badges visible in member directory cards
• Unique constraint: one badge type per user

##10.3 Leaderboard

• Weekly leaderboard resets correctly on Monday
• Monthly leaderboard resets on 1st of month
• All-time leaderboard sorted by reputation_score DESC
• User's own rank visible on leaderboard
• Cache TTL: 1 hour (Redis leaderboard:all)

#SECTION 11 — Notifications

##11.1 In-App Notifications

• All 12 notification types trigger correctly (see 12_Notifications_Module.md)
• Notifications saved to notifications table
• GET /notifications returns paginated inbox
• meta.unreadCount in response reflects actual unread count
• Mark single notification read: PATCH /notifications/:id/read
• Mark all read: POST /notifications/read-all
• Real-time delivery: notification Socket.io event to user:{userId} room
• Notification visible without page refresh

##11.2 Email Notifications

• Welcome email: delivered on registration
• Email verification: link works and verifies account
• Password reset: link works and is single-use
• Event confirmation: delivered on RSVP
• Event reminder: delivered 1 hour before event
• Generic notification email: delivered for enabled notification types
• All emails rendering correctly (not in spam — test with mail-tester.com)
• From address is a verified sending domain (SPF, DKIM, DMARC configured)
• Unsubscribe link present in all marketing/notification emails
• Unsubscribe flow works and updates preferences

##11.3 Notification Preferences

• Default preferences created for new users
• GET /notifications/preferences returns full preferences object
• PATCH /notifications/preferences updates preferences
• Disabled email preference: notification saved to DB but no email queued
• Disabled in_app preference: notification not saved, not delivered via socket

##11.4 BullMQ Email Queue

• email queue processing in EmailProcessor
• Failed jobs retry 3 times with exponential backoff
• Failed job does not crash the application
• Bull Board queue monitor accessible (at /api/v1/queues or via admin)

#SECTION 12 — Payments & Subscriptions

##12.1 Stripe Setup

• Stripe account is live (not test mode) in production
• All 3 products created in Stripe Dashboard: Starter ($29), Pro ($79), Elite ($197)
• Price IDs copied to production .env: STRIPE_STARTER_PRICE_ID, STRIPE_PRO_PRICE_ID, STRIPE_ELITE_PRICE_ID
• STRIPE_SECRET_KEY is sk_live_... in production
• Webhook endpoint registered in Stripe Dashboard: https://api.yourdomain.com/api/v1/payments/webhook
• STRIPE_WEBHOOK_SECRET copied to production .env
• Stripe Customer Portal enabled and configured in Dashboard
• Stripe Radar (fraud detection) enabled

##12.2 Checkout Flow

• GET /payments/plans returns all 3 plans with correct prices
• POST /payments/checkout { tier: 'pro' } returns checkoutUrl
• Stripe Checkout page loads and accepts test cards
• Successful payment → Stripe sends customer.subscription.created webhook
• users.membership_tier updates to pro after webhook processed
• User receives membership update notification
• Failed payment → invoice.payment_failed webhook handled
• Failed payment: subscriptions.status = 'past_due', email sent

##12.3 Billing Portal

• GET /payments/billing-portal returns Stripe portal URL
• Portal URL redirects to Stripe billing page
• User can cancel subscription from portal
• Cancellation → customer.subscription.deleted webhook
• Post-cancellation: users.membership_tier downgraded to starter
• Downgraded user loses Pro/Elite feature access immediately

##12.4 Webhook Reliability

• Raw body middleware active in main.ts (rawBody: true)
• Stripe signature verified on every webhook call
• Invalid signature → 400 Bad Request returned
• Webhook endpoint is @Public() (no JWT auth)
• Idempotent: duplicate webhook events don't double-apply tier changes
• Webhook processing tested with Stripe CLI: stripe listen --forward-to localhost/api/v1/payments/webhook

#SECTION 13 — Admin & Moderation

##13.1 Membership Applications

• Application form works (if separate from registration — collect business details)
• Application appears in admin queue: GET /admin/applications
• Admin can approve application → user account created + welcome email sent
• Admin can reject application → rejection email sent
• Admin can waitlist application
• Reviewer notes stored on each application decision

##13.2 Content Moderation

• GET /admin/moderation-queue returns flagged content
• Users can report a post (creates moderation queue item)
• Users can report a message (creates moderation queue item)
• Admin can remove content: post soft-deleted, reporter notified, poster notified
• Admin can warn user: notification sent + logged in moderation_logs
• Admin can suspend user: users.status = 'suspended', access blocked
• Admin can ban user: users.status = 'banned', all tokens revoked
• All admin actions logged in moderation_logs with moderator ID

##13.3 Analytics

• GET /admin/analytics returns: DAU, MAU, totalMembers, newMembersThisWeek
• Post count today, messages this week visible
• Revenue this month visible (from Stripe or subscriptions table)
• Churn rate calculated

##13.4 Broadcast

• Admin can send broadcast to: all members, or by tier (starter/pro/elite)
• In-app broadcast: notification delivered to all target users
• Email broadcast: email queued for all target users
• Broadcast visible in notification center

#SECTION 14 — Real-Time (Socket.io + Redis)

##14.1 Connection

• Socket.io server starts on same port as HTTP (3000)
• Nginx upgrades /socket.io/ path to WebSocket correctly
• JWT verified on socket handshake — invalid token disconnects socket
• User joins user:{userId} room on connect
• User presence set in Redis on connect: presence:{userId} = 'online'
• Presence expires after 5 minutes without heartbeat

##14.2 Room Management

• join_conversation joins conversation:{id} room (verified by participation)
• join_event joins event:{eventId} room (verified by RSVP)
• Unauthorized room join denied
• Room membership persists across reconnects

##14.3 All Events Tested

• new_message delivered instantly in conversation room
• message_read fires when conversation opened
• typing_start and typing_stop broadcast to other participants
• notification delivered to user:{userId} room
• presence_update broadcasts on connect and disconnect
• new_post emitted to feed:{channelId} room on post creation
• post_reacted emitted after reaction toggle
• event_started emitted to event:{eventId} room when event goes live
• event_ended emitted when event marked complete

##14.4 Redis Pub/Sub Adapter

• @socket.io/redis-adapter configured (Redis DB 4)
• Multi-instance test: message sent via instance A received on client connected to instance B
• Pub/sub client and sub client created correctly (separate Redis connections)

#SECTION 15 — Security Final Verification

##15.1 Secrets & Environment

• .env is in .gitignore — no secrets in version control
• JWT_ACCESS_SECRET ≥ 64 characters
• JWT_REFRESH_SECRET ≥ 64 characters, different from access secret
• COOKIE_SECRET ≥ 32 characters
• All secrets generated with openssl rand -hex 32
• BCRYPT_SALT_ROUNDS=12 confirmed
• No console.log statements logging passwords, tokens, or PII

##15.2 API Security

• ValidationPipe with whitelist: true, forbidNonWhitelisted: true active globally
• HttpExceptionFilter active globally (no stack traces in prod error responses)
• SWAGGER_ENABLED=false in production
• No sensitive data in error messages returned to clients
• SQL injection: all queries use TypeORM repository pattern (parameterized)
• XSS: user-generated HTML content sanitized before storage
• CSRF: checked for all state-changing endpoints
• Helmet.js security headers active

##15.3 Run Automated Checks

• ./ci/healthcheck.sh — all checks pass
• ./ci/release-gate.sh — all gates pass (exit code 0)
• ./ci/db-restore-validate.sh backup_file.sql.gz — all checks pass

#SECTION 16 — Compliance

• Terms of Service live at public URL
• Privacy Policy live at public URL
• Age gate on registration (18+ confirmation required)
• Consent checkboxes: ToS, Privacy Policy (required), Marketing email (optional)
• Consent timestamps stored in users table
• DELETE /members/me/account full GDPR erasure flow tested
• GET /members/me/data-export returns all user data as JSON
• Email unsubscribe link in all notification emails
• Unsubscribe flow tested end-to-end
• Stripe: only Stripe IDs stored — no card data anywhere in DB
• "Do Not Sell" language in Privacy Policy
• Apple Sign-In implemented (required for iOS app if any social login used)
• App Store Privacy Labels completed (when mobile app submitted)

#SECTION 17 — Monitoring & Observability

• GET /health endpoint returns { status: "ok" } with DB + Redis info
• Uptime monitor configured (UptimeRobot or equivalent), alert on downtime
• Container crash alerts configured (Portainer alerts or Docker health check alerts)
• docker compose logs accessible and structured (JSON format)
• PostgreSQL slow query log active (log_min_duration_statement=500)
• Log rotation configured on all containers
• Cron jobs verified running: backup, leaderboard refresh, cleanup, embedding refresh
• Test ci/healthcheck.sh gives clean output

#SECTION 18 — Final Sign-Off

##Feature Completeness Checklist

##Final Approval

Lead Engineer:          ________________________   Date: __________

Product Manager:        ________________________   Date: __________

Security Review:        ________________________   Date: __________

Go-Live Approved:  ☐ YES   ☐ NO — Reason: _________________________