Skip to main content

Definition of Done

Definition of DoneDone: Drop — Fintech Payment App

Project: {{PROJECT_NAME}}Drop — Remittance + QR Payments Version: {{VERSION}}1.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 draftDoD — fintech-specific with pass-through model invariants

1. Purpose

The Definition of Done (DoD) is a shared agreement across the Drop team on what must be true before any work item can be considered complete. It exists to:

  • Prevent technical debt accumulation through rushed or incomplete work
  • Ensure consistent quality across all team members and work types (Builder agent, Validator agent, John)
  • Create a shared language for "done" that developers, QA, and productAlem (CEO) all agree on
  • Prevent issues from reaching production that could have been caught earlier
  • Protect the pass-through model: Drop NEVER stores customer money, card numbers, or CVV data

Enforcement: The DoD is non-negotiable.negotiable Exceptionsfor requireDrop. Any exception requires explicit sign-off from theJohn Tech(AI LeadDirector) and must be tracked as technicala debtMission tickets.Control task with a linked risk acceptance from Alem Bašić (CEO). Undocumented shortcuts are not acceptable.acceptable in a fintech product.

2. Feature-Level DoD

When is a feature done?

Code Quality

  • Code is complete and implements all acceptance criteria from the ticketAC document (docs/BUSINESS-REQUIREMENTS/acceptance-criteria.md)
  • Code reviewed and approved by atValidator leastagent {{REVIEW_COUNT}}(read-only reviewer(s)reviewer)
  • All review comments resolved or explicitly deferred with documentationa Mission Control task
  • No TODO/FIXME comments left without corresponding ticketsMission Control tasks
  • Code follows Drop coding standards — naming,TypeScript, formatting,Next.js patternsApp Router patterns, parameterized SQL
  • No unnecessary dead code added
  • No console.log / debug statements left in production code

Testing — Drop Specific

  • Unit tests written for all new business logic (≥ {{UNIT_COV}}%80% coveragecoverage; on100% newfor code)auth + transaction logic)
  • Integration tests written for all new serviceAPI boundariesendpoints (API endpoints, DB queries, external calls)api-endpoints.test.ts)
  • E2EDB testscompliance writtenassertions foradded if any newschema criticalchanges user(db.test.ts journeys— no balance, no CVV)
  • All existing tests still pass (no regressions introduced)— all 40+ Vitest tests green)
  • Test coverage has not decreased below project minimum ({{MIN_COV}}%)80% overall)
  • Edge cases andtested: errorage conditionsboundary tested
    • (exactly
18),

Accessibility

amount
    boundaries
  • (100 AccessibilityNOK verifiedmin, —50,000 allNOK interactive elements keyboard navigablemax)
  • ARIAPass-through attributesinvariant correcttest: whereif needednew DB schema changes, db.test.ts must assert:
    • users table has NO balance column
    • cards Colortable contrasthas meetsNO WCAGcard_number AAor (4.5:1cvv for text, 3:1 for large text)columns
    Screen reader compatible (tested with {{SCREEN_READER}})
  •  No accessibility regressions (automated scan with {{A11Y_TOOL}} passes)

Security — Drop Fintech Standards

  • OWASP Top 10 checklist reviewed for this feature (especially if touching auth or payments)
  • Input validation in place for all user inputs (Zod schema — server-side)
  • Authorization checks correct (userJWT cancookie onlyrequired accessfor whatall they'reprotected permitted to)endpoints)
  • No sensitive data logged or(no exposedpasswords, no card numbers, no full JWT tokens in logs)
  •  No sensitive data in API responses (no password hashes, no full card numbers)
  • DependencyRate scanlimiting applies to new endpoints if they handle auth or financial actions
  •  CSRF token required on all new POST/PATCH/DELETE endpoints
  •  Parameterized SQL only — no string concatenation in DB queries
  •  npm audit passes (— no new HIGH/CRITICAL CVEs introduced)
  •  Security code review completed for authentication/authorization changesintroduced

Performance

  • Performance budget met — no P95 regression > {{PERF_REGRESSION}}%15% vs baseline (api-benchmarks.test.ts)
  • No N+1 query problems introduced(each API call makes a bounded number of DB queries)
  • Largebcrypt datasetstiming paginatedwithin or1,000ms streamedP95 (notafter loadedregistration/login into memory)changes)
  • Client-sideNo bundlesynchronous sizeheavy impactoperations reviewedblocking (ifthe frontendevent change)loop

Documentation

  • Code is self-documenting or has inline comments for non-obvious Drop business logic
  • READMEAPI reference updated if developernew setupendpoints changedadded (docs/backend/API-REFERENCE.md)
  • Architecture Decision Record created for significant architectural choices (e.g., pass-through model changes)
  • User-facingCLAUDE.md documentationor relevant project docs updated (if applicable)dev workflow changes

API (if applicable)

  • API documentation updated (OpenAPI spec / Postman collection)docs/backend/API-REFERENCE.md)
  • Breaking changes explicitly documented andin versioningrelease strategy appliednotes
  • BackwardsResponse compatibilityschema maintainedconsistent orwith migrationexisting guidepatterns provided(error format, HTTP status codes)

Error Handling

  • All error conditions handled gracefully (no unhandled promise rejections)
  • Error messages are user-friendly (noand in Norwegian where applicable
  •  No stack traces in production)
    • production
  • API Errors logged with appropriate severity and contextresponses
  • External service failures handled with(mock circuitBaaS breakerstimeout /→ fallbacksuser-friendly error)
  •  Financial errors use correct HTTP status codes (402 Insufficient Balance; 403 KYC Required)

ObservabilityCompliance Checklist (Drop-specific — MANDATORY)

  • LoggingPCI-DSS: No card_number or cvv stored or returned in full
  •  Pass-through model (ADR-003): No balance column added to users table
  •  AML: Transaction amounts ≤ 50,000 NOK enforced
  •  Age verification: Age ≥ 18 validation in place for significantany eventsnew (useruser-facing actions, errors, integrations)flows
  • MetricsAudit emittedtrail: forNew newfinancial featuresevents (request rate, error rate, business events)
  •  Alerts configured for new failure modes (if applicable)
  •  Traces instrumented for new service calls

Feature Flags

  •  Feature flag configured for the feature (if it's a significant or risky change)
  •  Flag documentedlogged in featureaudit_logs flag register
  •  Rollback plan documented (flag can be disabled to revert)table

Deployment

  • Deployed to staging (https://drop-staging.fly.dev/) and manually verified
  • Database migrations tested on staging (up and down)down migrations)
  • Environment variables documented forin any new configurationdocs/DEVELOPER-EXPERIENCE/local-development-setup.md
  • ProductFeature Ownerflag configured if the feature is gated (e.g., Cards, BankID)
  •  John (AI Director) has reviewed and accepted the feature in staging

3. Sprint-Level DoD

When is a sprint done?

  • All committed ticketsMission Control tasks meet their individual Definition of Done
  • All automated tests passing in CI (unit,Vitest: integration,40+ E2E)tests; Playwright: 3 projects)
  • Staging environment is stable (no broken features)features on https://drop-staging.fly.dev/)
  • Technical debt created during the sprint is tracked in theMission Control backlog
  • Sprint review conducted — stakeholdersJohn (AI Director) and Alem (CEO if available) have seen and accepted deliverables
  • Retrospective conductedfindings —logged processin improvements identified and documenteddocs/CROSS-CUTTING/lessons-learned.md
  • Next sprint's tickets aretasks refined and estimated
    • priority-ordered
  • in PerformanceMission baseline checked — no significant regressions vs last sprintControl

4. Release-Level DoD

When is a release done?

  • All features in scope meet the Feature-Level DoD
  • Full regression test suite passing on staging (all 26 API routes via api-endpoints.test.ts)
  •  Playwright E2E tests passing for all 5 critical userjourneys journeys(user-flows, full-flows, input-chaos)
  • Performance testbenchmarks passing — all SLAsNFR-P01..P06 targets met under load(api-benchmarks.test.ts)
  • Security scan complete — no unresolved HIGH/CRITICAL findings (npm audit clean)
  • AccessibilityDB auditcompliance completetests forpassing new/changed— UIdb.test.ts all assertions green (no balance, no CVV)
  • UAT conducted andwith Alem Bašić (CEO) sign-off obtained(or fromdocumented Productconditional Ownerapproval)
  • Release notes writtenwritten: and revieweddocs/RELEASE/release-notes.md
  • Deployment checklist completecomplete: (see docs/RELEASE/deployment-checklist.md)
  • Rollback plan prepared and testedtested: docs/RELEASE/rollback-plan.md
  • On-callJohn engineer(AI Director) briefed on all changes and potential failure modes
  • MonitoringSecurity dashboardsaudit updatedscore for≥ new80/100 features
    • (Phase
  • 0.5 All critical and high defects resolved or explicitly accepted with justificationrequirement)

5. Bug Fix DoD

When is a bug fix done?

  • Root cause understood and documented in the ticketMission Control task
  • Fix addresses root cause (not just symptoms)
  • Unit/integration test written that would have caught this bug (regression test)test added)
  • Fix does not introduce new failures (all 40+ tests still passing)
  • Fix verified in thestaging environment where the bug was reported
  • Related areas spot-checked for similar issues
  • BugMission ticketControl task updated with root cause and resolution notes
  •  docs/CROSS-CUTTING/lessons-learned.md updated if the bug reveals a systemic pattern

6. Hotfix DoD

When is a hotfix done?

  • Fix verified locally and on staging (cannot skip staging — even for hotfixes)
  • AtValidator least 1 revieweragent has approvedreviewed the fix (noat solominimum hotfixes)async review)
  • Smoke tests passing post-deployment (Playwright user-flows project)
  • IncidentMission ticketControl incident task updated with the fix details
  • Full regression test run scheduled within {{REGRESSION_SLA}}4 hours
  • Post-mortem scheduled within 24 hours if P1/P2 severity (DORA compliance)
  •  Rollback plan confirmed (Fly.io rollback ready in case hotfix causes regression)

7. CustomizationDrop-Specific GuideAdditions

Pass-Through Model Invariant (Non-Negotiable)

The following assertions must pass on Howevery tocommit adapt— thisthey DoD:are not optional:

// db.test.ts assertions — NEVER disable these:
expect(columns).not.toContain('balance')       // users table
expect(columns).not.toContain('card_number')   // cards table
expect(columns).not.toContain('cvv')           // cards table

If these tests fail, the build fails. No exceptions. No PR merges until fixed.

Financial Calculation Verification

All fee changes (currently 0.5% remittance, 1% QR) must include:

  1. ReviewUnit eachtest checklistin itemtransactions.test.ts —verifying markexact N/Afee if genuinely not applicable to your project typeamount
  2. AddBoundary project-specifictest itemsat minimum amount (100 NOK) and maximum amount (50,000 NOK)
  3. A comment in the appropriatecode section
  4. Adjust thresholds (coverage %, performance budget) to match your NFRs
  5. Get explicit agreement from all team members before finalizing
  6. Review and updatereferencing the DoDbusiness atrule each(BRD sprint retrospectivesection)

Norwegian Language Compliance

CommonUser-facing adaptations:error messages for age validation must include Norwegian text:

  • MobileAge apps:rejection: Add"Du devicemå testingvære matrix,minst app18 store submission requirementsår"
  • Backend-onlyOther services:messages: Remove/simplifyNorwegian accessibilityprimary, andEnglish UI performance itemssecondary
  • HighlyCheck: regulatedPlaywright environments:input-chaos.spec.ts Addincludes complianceNorwegian checkboxeserror (GDPR,message HIPAA, etc.)
  • Startups / early stage: Simplify coverage requirements while maintaining security basicsassertions

Approval

Role Name Date Signature
Author John (AI Director) 2026-02-23 Approved (AI)
ReviewerQA Lead Validator Agent 2026-02-23 Approved (AI)
ApproverTech Lead John 2026-02-23Approved
CEO (Alem)Alem BašićTBD
Back to top