Deployment Checklist: Drop — Fintech Payment App Deployment Checklist: Drop — Fintech Payment App Project: Drop — Remittance + QR Payments Version: 0.5.0 Date: 2026-02-23 Author: John (AI Director) Status: Approved Reviewers: Alem Bašić (CEO) Document History Version Date Author Changes 0.1 2026-02-23 John Initial draft — aligned to Phase 0.5 security hardening Deployment Metadata Field Value Version 0.5.0 Target Environment Staging → Production (Fly.io, Stockholm) Deployment Date TBD per release Deployment Time 02:00–06:00 CET (off-peak window) Deploy Engineer John (AI Director) Approver Alem Bašić (CEO) Deployment Type Standard Change Request # CR-001 Rollback Version 0.4.x (previous stable) 1. Pre-Deployment Checklist Code Quality Gates Code reviewed and approved — all PRs in this release have ≥ 1 approval (Alem or John) All unit tests passing — CI pipeline green on the release branch ( npm run test → 40+ tests pass) All integration tests passing — CI pipeline integration stage green ( npm run test:integration ) Code coverage meets minimum — ≥ 80% overall; 100% for auth + transaction paths (Vitest coverage) No HIGH/CRITICAL security findings — SAST scan clean; no open critical issues from security audit No secrets detected — no .env values committed; secret scanning clean Linting passes — npm run lint no errors in CI lint stage TypeScript compiles — npm run type-check passes with zero errors Staging Verification Staging deployment complete — artifact deployed to https://drop-staging.fly.dev/ E2E tests passing on staging — Playwright suite green (3 projects: user-flows, full-flows, input-chaos) Manual QA sign-off obtained — Validator agent has reviewed new features Performance baseline not degraded — P95 API within 10% of baseline (api-benchmarks.test.ts targets) Visual regression checks passed — UI screens match Figma-make export mockups Health endpoint responding — GET https://drop-staging.fly.dev/api/health returns {"status":"ok"} Database & Migrations Database migrations reviewed — SQL reviewed by a second person (John + Alem) Migrations tested on staging — ran successfully; SQLite dev / PostgreSQL staging verified Down/rollback migration tested — migrate down executes without errors on staging Migration script idempotent — safe to run twice without errors Estimated migration time on production documented: < 2 min (schema-only, no data migration in Phase 0.5) Data backup taken before migration — Fly.io volume snapshot taken; backup ID recorded Pass-through model verified — users table has NO balance column; cards table has NO card_number or cvv columns (db.test.ts passes) Environment & Configuration All environment variables documented — updated in Vaultwarden ( vault.basicconsulting.no ) New secrets provisioned — JWT_SECRET , DATABASE_URL , SUMSUB_API_KEY (mock), BAAS_API_KEY (mock) set in Fly.io secrets Configuration changes reviewed — no unintended env var drift from staging External API keys — Sumsub and BaaS keys are mock/sandbox credentials (MVP only; real in Phase 2) NEXT_PUBLIC_SERVICE_MODE — set to mock for MVP; never live until BaaS partnership confirmed NEXT_PUBLIC_FEATURE_FLAGS — Cards feature flag OFF in production BankID keys — Phase 2 only; not required for MVP Feature Flags Feature flags configured — new features default OFF in production Cards feature flag = OFF — requires card partner onboarding (Phase 3) BankID flag = OFF — Phase 2 feature; DOB validation active in MVP Kill switches in place for QR payments and Remittance (env var toggle) Feature flag audit complete — no stale flags from previous releases Rollback Readiness Rollback plan documented — see Section 5 and rollback-plan.md Previous version artifact available — drop-app:v0.4.x Docker image in Fly.io registry Rollback tested on staging — flyctl deploy --image drop-app:v0.4.x tested successfully Rollback owner assigned — John (AI Director) is available during deployment window Rollback time < 5 minutes confirmed (Fly.io blue/green instant rollback) Operational Readiness On-call engineer notified — Alem Bašić aware and available during deployment window Deployment window confirmed — 02:00–06:00 CET (off-peak; lowest user traffic for Norway corridor) Monitoring dashboards open — Fly.io metrics dashboard ready Slack channel ready — #drop-deploy on alai-talk.slack.com Change request approved — CR-001 approved by Alem Bašić 2. During Deployment Step Time Actor Status Notes Announce deployment start in #drop-deploy Slack John "Deploying Drop v0.5.0 to production" Enable maintenance mode (if required) John Set MAINTENANCE_MODE=true env var Trigger deployment: flyctl deploy --app drop-app John Monitor Fly.io deployment logs Monitor deployment progress John Watch for health check failures Run database migrations (if applicable) John npm run db:migrate on Fly.io console Verify migration success: flyctl ssh console -a drop-app John Check no orphaned records Confirm new instances healthy (health checks green) John Fly.io load balancer shows 2/2 healthy Confirm all instances running new version John flyctl status --app drop-app Run smoke tests Validator npx playwright test --project=user-flows Verify health endpoint: curl https://getdrop.no/api/health John Expect {"status":"ok","db":"connected"} Disable maintenance mode (if enabled) John Set MAINTENANCE_MODE=false Announce deployment complete in #drop-deploy John Include version and health status 3. Post-Deployment Checklist Immediate Verification (First 15 Minutes) Health checks passing — GET /api/health returns 200 with {"status":"ok","db":"connected"} Smoke tests pass — Playwright user-flows suite green on production Critical user journey manual test — manually verify: Registration → OTP → PIN → Login → Dashboard Error rate normal — < 0.1% on Fly.io metrics dashboard P99 latency normal — < 500ms (standard endpoints); < 1,000ms (bcrypt operations) Database connections normal — no connection pool saturation No unexpected errors in logs — flyctl logs --app drop-app shows clean logs Feature Validation (First 30 Minutes) Registration flow functional — test with valid Norwegian phone (+47) and DOB ≥ 18 Login + JWT cookie set — httpOnly, SameSite=Strict, 7-day expiry verified Remittance flow functional — test with mock BaaS; fee calculation correct (0.5%) QR payment flow functional — test with mock merchant; fee correct (1%) Exchange rates returning — GET /api/rates returns 6 NOK corridors (RSD, BAM, PKR, TRY, PLN, EUR) Cards feature flag OFF — no Cards UI exposed Rate limiting active — 10+ auth requests → 429 response Monitoring Setup (First 60 Minutes) Performance baseline compared — P95 matches staging baseline CPU and memory normal — Fly.io metrics; no upward trend Stakeholders notified — Alem Bašić notified via MCP email (john@alai.no → alem@alai.no) Release notes published — release-notes.md updated Security audit score maintained — no regression from Phase 0.5 hardening (target: ≥ 80/100) 4. Rollback Procedure (Quick Reference) Rollback triggers (any one sufficient): Smoke tests fail after deployment Error rate > 1% for > 5 consecutive minutes P99 > 2,000ms sustained Data integrity issue detected (e.g., balance column found in users table) Security vulnerability actively exploited Rollback authorization: John (AI Director) or Alem Bašić (CEO) Rollback steps: # 1. Announce in #drop-deploy: "Initiating rollback to v0.4.x" # 2. Trigger Fly.io rollback (instant, < 2 min): flyctl deploy --app drop-app --image drop-app:v0.4.x # 3. If DB migration was included — run down migration: flyctl ssh console -a drop-app -C "npm run db:migrate:down" # 4. Verify rollback: curl https://getdrop.no/api/health npx playwright test --project=user-flows Expected rollback time: 2–5 minutes (Fly.io blue/green) Full rollback procedure: rollback-plan.md 5. Emergency Deployment Process Emergency deployments require: Sign-off from Alem Bašić (CEO) or John (AI Director) At least 1 code reviewer (can be async if truly urgent) Staging deployment and smoke test (cannot be skipped — even for emergencies) Enhanced post-deploy monitoring for 4h Full retroactive change request within 24h of deployment Emergency deployment allowed: Security vulnerabilities (e.g., auth bypass), data loss bugs, P1 service outages 6. Deployment Window & Blackout Periods Standard deployment window: Tuesday–Thursday, 02:00–06:00 CET Emergency deployments: Any time, with CEO or AI Director approval Blackout periods (no production deployments): Period Dates Reason Finanstilsynet submission window TBD Regulatory review — no changes during evaluation BaaS partner onboarding TBD (Phase 2) Partner integration stability required Norwegian bank holidays Per year Minimal engineering support available Sign-Off Pre-deployment confirmed by: John (AI Director) Deployment completed by: John (AI Director) Post-deployment verified by: Validator agent + John (AI Director) Related Documents Release Notes Rollback Plan UAT Sign-Off Approval Role Name Date Signature Author John (AI Director) 2026-02-23 Approved (AI) Tech Lead John 2026-02-23 Approved AI Director (John) John 2026-02-23 Approved CEO (Alem) Alem Bašić TBD