Deployment Checklist

Deployment ChecklistChecklist: Drop — Fintech Payment App

Project: {{PROJECT_NAME}}Drop — Remittance + QR Payments Version: {{VERSION}}0.5.0 Date: {{DATE}}2026-02-23 Author: {{AUTHOR}}John (AI Director) Status: Draft | In Review | Approved Reviewers: {{REVIEWERS}}Alem Bašić (CEO)

Document History

Version	Date	Author	Changes
0.1	{{DATE}}2026-02-23	{{AUTHOR}}John	Initial draft — aligned to Phase 0.5 security hardening

---

Deployment Metadata

Field	Value
Version	{{VERSION}}0.5.0
Target Environment	{{ENVIRONMENT}}Staging → Production (Fly.io, Stockholm)
Deployment Date	{{DATE}}TBD per release
Deployment Time	{{TIME}}02:00–06:00 {{TIMEZONE}}CET (off-peak window)
Deploy Engineer	{{ENGINEER}}John (AI Director)
Approver	{{APPROVER}}Alem Bašić (CEO)
Deployment Type	{{TYPE}} Standard
Change Request #	{{CR_NUMBER}}CR-001
Rollback Version	{{ROLLBACK_VERSION}}0.4.x (previous stable)

---

1. Pre-Deployment Checklist

Code Quality Gates

• Code reviewed and approved — all PRs in this release have ≥ {{REVIEW_COUNT}}1 approvalsapproval (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 — ≥ {{COV_GATE}}%80% overall; 100% for auth + transaction paths (current:Vitest {{CURRENT_COV}}%)coverage)
• No HIGH/CRITICAL security findings — SAST andscan SCAclean; scansno cleanopen 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 — this exact artifact has been deployed to staginghttps://drop-staging.fly.dev/
• E2E tests passing on staging — automatedPlaywright suite green ({{PASS_COUNT}}/{{TOTAL_COUNT}}3 tests)projects: user-flows, full-flows, input-chaos)
• Manual QA sign-off obtained — QAValidator teamagent has reviewed new features
• Performance baseline not degraded — P95 API within {{PERF_GATE}}%10% of baseline (api-benchmarks.test.ts targets)
• Visual regression checks passed (if— UI changes)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,successfully; durationSQLite recorded:dev {{MIGRATION_TIME}}min/ 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: {{PROD_MIGRATION_TIME}}< 2 min (schema-only, no data migration in Phase 0.5)
• Data backup taken before migration (if destructive migration) — Fly.io volume snapshot taken; backup ID:ID {{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 and— updated in {{SECRET_STORE}}Vaultwarden (vault.basicconsulting.no)
• New secrets provisioned — JWT_SECRET, DATABASE_URL, SUMSUB_API_KEY (mock), BAAS_API_KEY (mock) set in productionFly.io secret storesecrets
• Configuration changes reviewed — no unintended changesenv var drift from staging
• External API keys — Sumsub and BaaS keys are livemock/sandbox credentials (notMVP sandbox)only; credentialsreal in Phase 2)
• DNS records verifiedNEXT_PUBLIC_SERVICE_MODE (if— changesset required)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 allQR newpayments significantand features
Remittance
• (env Rolloutvar plan documented — which flags, in what order, over what timelinetoggle)
• 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 — {{PREV_IMAGE}}drop-app:v0.4.x Docker image in Fly.io registry
• Rollback tested on staging (if— DBflyctl migrationsdeploy are--image included)drop-app:v0.4.x tested successfully
• Rollback owner assigned — {{ROLLBACK_OWNER}}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 — {{ONCALL}}Alem isBašić aware and available during deployment window
• Deployment window confirmed — {{TIME}}02:00–06:00 - {{END_TIME}}CET (off-peak)peak; lowest user traffic for Norway corridor)
• Monitoring dashboards open and— Fly.io metrics dashboard ready
• WarSlack roomchannel set upready — {{WAR_ROOM_LINK}}#drop-deploy on alai-talk.slack.com
• Change request approved — CR-{{CR_NUMBER}}001 approved by {{APPROVER}}Alem on {{DATE}}Bašić

---

2. During Deployment

Step	Time	Actor	Status	Notes
Announce deployment start in war#drop-deploy roomSlack		{{ENGINEER}}John		"Deploying Drop v0.5.0 to production"
Enable maintenance mode (if required)		{{ENGINEER}}John		Set MAINTENANCE_MODE=true env var
Trigger deployment pipeline:deployment: {{PIPELINE_LINK}}flyctl deploy --app drop-app		{{ENGINEER}}John		Monitor Fly.io deployment logs
Monitor deployment progress		{{ENGINEER}}John		WatchingWatch for errorshealth check failures
Run database migrations (if applicable)		{{DB_OWNER}}John		Duration:npm {{TIME}}minrun db:migrate on Fly.io console
Verify migration success: {{VERIFY_CMD}}flyctl ssh console -a drop-app		{{DB_OWNER}}John		Check no orphaned records
Confirm new instances healthy (health checks green)		{{ENGINEER}}John		Fly.io load balancer shows 2/2 healthy
Confirm all instances running new version		{{ENGINEER}}John		flyctl status --app drop-app
Run smoke tests: bash scripts/smoke-tests.sh {{ENV}}tests		{{QA}}Validator		npx playwright test --project=user-flows
Verify health endpoint: curl {{URL}}https://getdrop.no/api/health		{{ENGINEER}}John		Expect {"status":"ok","db":"connected"}
Disable maintenance mode (if enabled)		{{ENGINEER}}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 — allGET instances/api/health healthyreturns per200 loadwith balancer{"status":"ok","db":"connected"}
• Smoke tests pass — automatedPlaywright smokeuser-flows suite green on production
• Critical user journey manual test — manually verifyverify: {{CRITICAL_JOURNEY}}Registration → OTP → PIN → Login → Dashboard
• Error rate normal — < {{ERROR_THRESHOLD}}%0.1% (checkon {{DASHBOARD_LINK}})Fly.io metrics dashboard
• P99 latency normal — < {{P99_THRESHOLD}}ms500ms (standard endpoints); < 1,000ms (bcrypt operations)
• Database connections normal — no connection pool saturation
• No unexpected errors in logs — {{LOG_DASHBOARD_LINK}}flyctl logs --app drop-app shows clean logs

Feature Validation (First 30 Minutes)

• NewRegistration featuresflow functional — quick manual test ofwith eachvalid featureNorwegian inphone scope(+47) and DOB ≥ 18
• FeatureLogin flags+ enabledJWT percookie rollout planset — {{FF_DASHBOARD}}httpOnly, showsSameSite=Strict, correct7-day stateexpiry verified
• Third-partyRemittance integrationsflow workingfunctional — payments,test email,with externalmock APIsBaaS; respondingfee calculation correct (0.5%)
• VersionQR confirmedpayment flow functional — test with mock merchant; fee correct (1%)
•  Exchange rates returning — GET /api/versionrates or equivalent returns {{VERSION}}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 or beats staging baseline
• CPU and memory normal — Fly.io metrics; no upward trend
•  Alerting verified — test alert confirms delivery to on-call
• Stakeholders notified — releaseAlem announcementBašić sentnotified tovia {{NOTIFY_LIST}}MCP email ([email protected] → [email protected])
• DocumentationRelease updatednotes published — releaserelease-notes.md notesupdated
published
•  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 > {{ROLLBACK_ERROR}}%1% for > {{ROLLBACK_DURATION}}5 consecutive minutes
• P99 > {{ROLLBACK_P99}}ms2,000ms sustained
• Data integrity issue detected (e.g., balance column found in users table)
• Security vulnerability actively exploited

Rollback authorization: {{ROLLBACK_AUTHORITY}}John (AI Director) or seniorAlem engineerBašić on duty(CEO)

Rollback steps:

# 1. Announce in war room:#drop-deploy: "Initiating rollback to {{ROLLBACK_VERSION}}"v0.4.x"

# 2. Trigger rollback:Fly.io {{ROLLBACK_CMD}}rollback (instant, < 2 min):
flyctl deploy --app drop-app --image drop-app:v0.4.x

# 3. If DB migration was included — run down migration:
{{DOWN_MIGRATION_CMD}}flyctl ssh console -a drop-app -C "npm run db:migrate:down"

# 4. Verify rollback:
curl {{URL}}https://getdrop.no/api/health
bashnpx scripts/smoke-tests.shplaywright {{ENV}}test --project=user-flows

Expected rollback time: {{ROLLBACK_TIME}}2–5 minutes (Fly.io blue/green) Full rollback procedure: rollback-plan.md

---

5. Emergency Deployment Process

Emergency deployments require:

1. Sign-off from {{EMERGENCY_AUTHORITY}}Alem Bašić (Engineering ManagerCEO) or above)John (AI Director)
2. At least {{EMERGENCY_REVIEWS}}1 code reviewer (can be async if truly urgent)
3. Staging deployment and smoke test (cannot be skipped)skipped — even for emergencies)
4. Enhanced post-deploy monitoring for {{EMERGENCY_MONITOR}}h4h
5. Full retroactive change request within {{CR_SLA}}h24h of deployment

Emergency deployment allowed: Security vulnerabilities,vulnerabilities (e.g., auth bypass), data loss bugs, P1 service outages

---

6. Deployment Window & Blackout Periods

Standard deployment window: {{DEPLOY_WINDOW}}Tuesday–Thursday, 02:00–06:00 CET Emergency deployments: Any time, with approvalsCEO or AI Director approval

Blackout periods (no production deployments):

Period	Dates	Reason
EndFinanstilsynet ofsubmission yearwindow	{{EOY_START}} – {{EOY_END}}TBD	HighRegulatory traffic,review minimal— supportno changes during evaluation
{{EVENT_1}}BaaS partner onboarding	{{DATE_1}}TBD (Phase 2)	{{REASON_1}}Partner integration stability required
{{EVENT_2}}Norwegian bank holidays	{{DATE_2}}Per year	{{REASON_2}}Minimal engineering support available

---

Sign-Off

Pre-deployment confirmed by: {{ENGINEER}}John on(AI {{DATE}} at {{TIME}}Director) Deployment completed by: {{ENGINEER}}John on(AI {{DATE}} at {{TIME}}Director) Post-deployment verified by: {{ENGINEER}}Validator onagent {{DATE}}+ atJohn {{TIME}}(AI Director)

---

Related Documents

• Release Notes
• Rollback Plan
• Go-LiveUAT Runbook
• Operational RunbookSign-Off

---

Approval

Role	Name	Date	Signature
Author	John (AI Director)	2026-02-23	Approved (AI)
ReviewerTech Lead	John	2026-02-23	Approved
ApproverAI Director (John)	John	2026-02-23	Approved
CEO (Alem)	Alem Bašić	TBD