Tech Debt Log

Tech Debt Log: {{PROJECT_NAME}}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 drafttech debt log — Phase 0/0.5 items captured

---

1. Tech Debt Philosophy

Technical debt is not inherently bad. Sometimes taking on debt is the right business decision (shipping faster to meet a deadline). The problem is unacknowledged and unmanaged debt.

This log exists to:

1. Make invisible debt visible
2. Enable informed decisions about when to repay debt
3. Track the "interest" — how debt is slowing the team down
4. Demonstrate to stakeholders that quality is actively managed

Debt Entry Trigger: Any time you make a technical shortcut, write a workaround, defer a refactor, skip a test, or make a "we'll fix this later" comment — add an entry here.

Drop-Specific Constraint: Drop is a fintech pass-through app under PSD2/AML regulation. Security and compliance debt (categories: Security, Design) get automatic P1 treatment regardless of impact score. No security debt survives more than 1 sprint without explicit CEO risk acceptance.

---

2. Summary Dashboard

Metric	Current	Last Sprint	Trend
Total Items	{{COUNT}}9	{{COUNT}}3	{{↑/↓/→}}
Open	{{COUNT}}6	{{COUNT}}3	{{↑/↓/→}}
In Progress	{{COUNT}}1	{{COUNT}}0	{{↑/↓/→}}
Resolved	{{COUNT}}2	{{COUNT}}0	{{↑/↓/→}}
Critical / High (P1/P2)	{{COUNT}}3	{{COUNT}}2	{{↑/↓/→}}
Debt in current sprint	{{COUNT}}1	{{COUNT}}0	{{↑/↓/→}}
Avg age of open items (days)	{{DAYS}}14	{{DAYS}}14	{{↑/↓/→}}
Debt resolved this sprint	{{COUNT}}2	{{COUNT}}0	{{↑/↓/→}}

Sprint Debt Budget: {{X}}%20% of sprint capacity allocated to debt reduction (recommended:Phase 15-20%)0.5 security hardening sprint exceeded this — security debt is P1 mandatory)

---

3.2. Tech Debt Categories

Category	Description	Common Causes	Detection Method
Design	Architectural shortcuts, wrong abstractions, poor separation of concerns	Time pressure, evolving requirements	Code review, architecture review
Code Quality	Duplication, high complexity, poor naming, missing documentation	Speed over quality, lack of standards	Static analysis (SonarQube),analysis, code review
Infrastructure	Manual processes, missing monitoring, config drift, single points of failure	Growth outpacing ops maturity	Ops review, incident postmortems
Documentation	Missing or outdated technical docs, undocumented decisions, no onboarding guide	Documentation deferred, never caught up	New team member feedback, ops incidents
Dependency	Outdated libraries, deprecated APIs, unmaintained packages, version conflicts	Insufficient update cadence	Automated scan (Snyk/Dependabot)npm audit)
Testing	Low coverage, flaky tests, missing integration tests, untested edge cases	Speed over quality	Coverage reports, incident analysis
Security	Known vulnerabilities not yet patched, security shortcuts taken	Urgency, lack of security knowledge	Security scans,scan, CVE alerts
Performance	Known bottlenecks, inefficient queries, N+1 problems, no caching	Optimizations deferred	Performance monitoring,api-benchmarks.test.ts, load tests

---

4.3. Impact Assessment Methodology

4.3.1 Impact Score (1–10)

Score	Impact Level	Effect on Team/Business
1–2	Negligible	Cosmetic; no measurable effect on velocity or product
3–4	Minor	Slightly slows specific tasks; <5% velocity impact
5–6	Moderate	Slows multiple tasks; 5–15% velocity impact; occasional bugs
7–8	High	Significantly slows development; 15–30% velocity impact; recurring bugs
9–10	Critical	Blocks progress; >30% velocity impact; high risk of production incidents

4.3.2 Effort to Fix (Story Points)

Size	Points	Typical Scope
XS	1	Single line / config change
S	2–3	Single function / component refactor
M	5–8	Module-level changes; cross-cutting update
L	13	Multi-module refactoring; architecture change
XL	21+	Major refactor; break into sub-tasks first

4.3.3 Priority Calculation

Priority = Impact Score × (1 / Effort) — High impact, low effort = P1

Priority	Criteria	Sprint Allocation Target
P1 — Critical	Impact ≥ 8 OR blocks release OR any Security debt	Schedule within 1 sprint
P2 — High	Impact 6–7	Schedule within 2 sprints
P3 — Medium	Impact 4–5	Schedule within 4 sprints
P4 — Low	Impact ≤ 3	Schedule when convenient

---

5.4. Tech Debt Register

ID	Description	Category	Introduced	Impact (1-10)	Effort	Priority	Owner	Status	Target Resolution	Review Date	Notes
TD-001	{{DESCRIPTION}}SQLite has ~200 concurrent write limit. Under load, users may experience database is locked errors. Migration to PostgreSQL (Phase 1) is the full fix.	{{CATEGORY}}Performance	{{DATE_OR_SPRINT}}Phase 0	{{1-10}}8	{{XS/S/M/L/XL}}L	P{{1-4}}P1	{{@OWNER}}John	Open	{{DATE}}Phase 1 launch	{{DATE}}2026-03-01	{{CONTEXT}}NFR-S02 documents this. SQLite WAL mode mitigates but does not eliminate. Blocks production scale.
TD-002	BaaS integration mocked via NEXT_PUBLIC_SERVICE_MODE=mock. No real SpareBank1 or Swan connection. All transactions are simulated.	Code QualityDesign	Phase 0	10	XL	P1	John	Open	Phase 2 (BaaS partner confirmed)	2026-03-01	Blocks real money movement. BaaS partner pitch in progress. Cannot launch for real users until resolved.
TD-003	KYC integration uses mock Sumsub. User identity verification is not real — any user can pass KYC in dev/staging.	TestingSecurity	Phase 0	10	L	P1	John	In ProgressOpen	Phase 2 (Sumsub live integration)	2026-03-01	Blocks regulatory compliance. MUST be live before real user onboarding. Sumsub account manager contact transferred to John.
TD-004	In-memory rate limiting (Node process memory) resets on server restart. Was Phase 0 implementation.	ArchitectureSecurity	Phase 0	7	M	P1	Builder Agent	OpenResolved	Phase 0.5 (resolved)	2026-02-23	RESOLVED in Phase 0.5 — replaced with DB-backed rate limiting using rate_limit_requests table. Per-user + per-IP persistence survives restarts.
TD-005	No bcrypt password length limit — malicious users could submit 10,000-character passwords and trigger bcrypt DoS (bcrypt has O(n) cost on input length).	DependenciesSecurity	Phase 0	7	XS	P1	Builder Agent	OpenResolved	Phase 0.5 (resolved)	2026-02-23	RESOLVED in Phase 0.5 — 1,000-character max input validation added in Zod schema before bcrypt. Regression test added.
TD-006	Exchange rates are static seed data. No real rate feed from external provider. Rates in db/seeds/rates.sql do not auto-update.	InfrastructureDesign	Phase 0	6	M	P2	John	Open	Phase 2	2026-04-01	Acceptable for MVP/demo. Phase 2 requires live rate feed (e.g., Open Exchange Rates API or Wise API).
TD-007	BankID integration fully mocked. Age verification (≥18) and Norwegian residency checks use mock data only.	DocumentationSecurity	Phase 0	9	L	P1	John	Open	Phase 1 or Phase 2	2026-03-01	Regulatory requirement. BankID = mandatory per Norwegian PSD2 + AML. Cannot serve real users without it. Finanstilsynet registration in progress.
TD-008	No structured logging / APM in place. console.log used for debug output in some modules. No Fly.io metrics integration beyond basic health check.	SecurityInfrastructure	Phase 0	5	M	P3	John	Open	Phase 1	2026-04-01	Low risk for MVP/demo. Phase 1 needs structured logging (e.g., Pino) + Fly.io metrics + Sentry error tracking.
TD-009	Cards feature has no real card partner integration. Feature is behind CARDS_ENABLED=false flag — cards data is mocked, no real card issuing.	PerformanceDesign	Phase 0	3	XL	P4	John	Open	Phase 3+	2026-06-01	Low priority. Cards are explicitly Phase 3. Feature flag prevents exposure. No action needed for Phase 0.5 or Phase 1.

Status Values: Open | In Progress | Resolved | Accepted (deferred) | Won't Fix (justified)

---

6.5. Prioritization Framework

6.5.1 Cost of Delay Analysis

ID	Description	Cost Per Sprint (velocity loss %)	Number of Sprints Open	Accumulated Cost
TD-001	{{DESCRIPTION}}SQLite concurrent limit	{{X}}%~5% (affects test reliability under concurrency)	{{COUNT}}1	{{ACCUMULATED_COST}}~5% velocity
TD-002	Mock BaaS	Blocks real revenue (100% blocker for live transactions)	1	Cannot launch
TD-003	Mock KYC	Blocks regulatory compliance (100% blocker for real users)	1	Cannot launch
TD-007	Mock BankID	Blocks age verification + AML compliance (100% blocker)	1	Cannot launch

6.5.2 Debt Payoff Prioritization

When multiple P3 items compete for sprint capacity, use:

1. Quick wins first — Impact ≥ 5 AND Effort ≤ S (high ROI)
2. Blocker debt — Any item that blocks a planned feature or regulatory milestone
3. Aging debt — Items open > 3 sprints get auto-elevated one priority
4. Security debt — Always scheduled within 1 sprint regardless of impact score

Drop Rule: TD-002, TD-003, TD-007 (BaaS, KYC, BankID) are NOT fixed by code changes alone — they require confirmed external partners. Track separately as business dependencies, not engineering tasks.

---

7.6. Sprint Debt Allocation Guidelines

Team Velocity	Debt Budget (15%20%)	Recommended Items to Schedule
20 points/sprint (AI agents)	4 points	1–2 S items or 1 M item
40 points/sprint	68 points	2–3 S items or 1 M item
60 points/sprint	9 points	3–4 S items or 1 M + 1 S
80 points/sprint	12 points	1 L item or 2 M items

Sprint Debt Review (each sprint planning):

1. PMJohn +(AI TechDirector) Lead reviewreviews open debt register (15 min)
2. Select debt items for sprint based on budget and priority
3. Add selected items to sprint backlog as technical tasks in Mission Control
4. Update status of in-progress items

---

8.7. Debt Reduction Tracking

Sprint	Debt Items Added	Debt Items Resolved	Net Change	Running Total Open
SprintPhase 10	{{COUNT}}9	{{COUNT}}0	{{+/-}}9	{{COUNT}}9
SprintPhase 0.5	0	2 (TD-004, TD-005)	-2				7
SprintPhase 31	TBD	TBD (TD-001, TD-008 targets)	TBD	TBD

Debt Trend: {{INCREASINGDECREASING /(Phase STABLE0.5 /resolved DECREASING}}2 security items; 3 blockers are external business dependencies, not engineering debt)

---

9.8. Trend Analysis

9.8.1 Debt by Category (thisPhase quarter)0 → Phase 0.5)

Category	Items Added	Items Resolved	Net
Design	3 (TD-002, TD-006, TD-009)	0	+3
Security	4 (TD-003, TD-004, TD-005, TD-007)	2 (TD-004, TD-005)	+2
Infrastructure	1 (TD-008)	0	+1
Performance	1 (TD-001)	0	+1
Code Quality	{{COUNT}}0	{{COUNT}}0	{{+/-}}0
Testing	0	0
Architecture
Dependencies
Infrastructure			0
Documentation	0	0	0
SecurityDependency	0	0
Performance			0

9.8.2 Root Cause Analysis

Dominant category this quarter: {{CATEGORY}}Security + Design (MVP shortcuts) Suspected root cause: {{ROOT_CAUSE}}MVP phase deliberately chose mock integrations (BaaS, KYC, BankID) to ship working architecture without blocked external partners. This is intentional, managed debt — not negligence. Proposed systemic fix: {{FIXBusiness —dependency hook/tool/process/rule}}tracking separate from engineering debt. TD-002/003/007 are tracked in the ROADMAP.md as Phase 2 blockers and require Alem Bašić (CEO) partner decisions, not engineering sprints.

---

10.9. Resolved / Accepted Debt Archive

ID	Description	Resolution	Resolution Date	Sprint	Resolved By
TD-{{RESOLVED}}004	{{DESCRIPTION}}In-memory rate limiting resets on restart	{{HOW_FIXED}}Replaced with DB-backed rate_limit_requests table; persistent across restarts	{{DATE}}2026-02-23	SprintPhase {{X}}0.5	{{@OWNER}}Builder Agent
TD-005	No password length limit — bcrypt DoS vector	Added Zod max(1000) validation before bcrypt hash; regression test in auth.test.ts	2026-02-23	Phase 0.5	Builder Agent

---

Related Documents

• Risk Register
• Security Audit Report
• Lessons Learned
• Architecture Decision Records

---

Approval

Approved

Role	Name	Date	Signature
Author	John (AI Director)	2026-02-23
Reviewer			(AI)
Tech Lead	John	2026-02-23	Approved
AI DirectorCEO (John)Alem)	Alem Bašić	TBD