ADR Overview
Architecture Decision Records (ADRs)
Project: Drop -- Fintech Payment App Last updated: 2026-03-03 Maintainer: Standards Architect
What are ADRs?
Architecture Decision Records capture significant technical decisions made during Drop's development. Each ADR documents the context, the decision itself, and its consequences -- providing a historical record of why the system is built the way it is.
ADRs are immutable once accepted. If a decision is reversed, the original ADR is marked Superseded and a new ADR is created referencing it.
ADR Index
| ADR | Title | Status | Date | Category |
|---|---|---|---|---|
| ADR-001 | Consolidate to Single Backend | Accepted | 2026-02-12 | Architecture |
| ADR-002 | Separate FontelePay from Drop Repository | Accepted | 2026-02-12 | Architecture |
| ADR-003 | Adopt PSD2 Pass-through Model (No Wallet) | Accepted | 2026-02-12 | Architecture |
| ADR-004 | JWT Storage in httpOnly Cookies | Accepted | 2026-02-21 | Security |
| ADR-005 | Monolith-First Architecture | Accepted | 2026-02-21 | Architecture |
| ADR-006 | SQLite for Dev, PostgreSQL for Production | Superseded by ADR-014 | 2026-02-21 | Database |
| ADR-007 | BankID as Sole Authentication Provider | Accepted | 2026-02-21 | Security |
| ADR-008 | Hono v4 for Mobile API | Accepted | 2026-02-21 | Backend |
| ADR-009 | Custom Feature Flag System | Accepted | 2026-02-21 | Backend |
| ADR-010 | Dual Database Driver Abstraction | Superseded by ADR-014 | 2026-02-21 | Database |
| ADR-011 | Expo SDK 54 for Mobile App | Accepted | 2026-02-21 | Mobile |
| ADR-012 | AWS App Runner for Deployment | Accepted | 2026-02-21 | Infrastructure |
| ADR-014 | PostgreSQL-Only Architecture (Drizzle ORM) | Accepted | 2026-02-26 | Database |
ADR Lifecycle
stateDiagram-v2
[*] --> Proposed : Author drafts ADR
Proposed --> Accepted : Team reviews and approves
Proposed --> Rejected : Team rejects proposal
Accepted --> Deprecated : No longer relevant
Accepted --> Superseded : New ADR replaces this one
Rejected --> [*]
Deprecated --> [*]
Superseded --> [*]
ADR Template
Use this template when proposing a new ADR. Save as ADR-NNN-short-title.md in this directory.
# ADR-NNN: Title
**Status:** Proposed | Accepted | Deprecated | Superseded by [ADR-XXX](ADR-XXX-title.md)
**Date:** YYYY-MM-DD
**Deciders:** [Names and roles]
**Category:** Architecture | Security | Database | Backend | Frontend | Mobile | Infrastructure
---
## Context
What is the issue that we are seeing that motivates this decision?
Include technical background, constraints, and forces at play.
## Decision
What is the change that we are proposing and/or doing?
State the decision clearly and concisely.
## Consequences
### Positive
- List benefits of this decision
### Negative
- List drawbacks and trade-offs
### Risks
- List risks and their mitigations
## References
- Link to related ADRs, documents, or external resources
- Link to implementation PRs or tasks
Guidelines for Proposing ADRs
-
When to write an ADR: Any decision that affects the system architecture, technology choices, security model, or data model and would be hard to reverse.
-
Scope: One ADR per decision. If a decision has multiple parts, consider splitting into separate ADRs.
-
Numbering: Use sequential three-digit numbers (001, 002, ...). Never reuse numbers.
-
Review process: Draft as
Proposed, share with the team. Once approved by the AI Director (John) and/or CEO (Alem), change status toAccepted. -
Superseding: When reversing a decision, create a new ADR and update the old one's status to
Superseded by [ADR-XXX]. Never delete old ADRs. -
Context matters: Future readers need to understand why the decision was made. Include constraints, alternatives considered, and the reasoning.
Cross-References
- Architecture Document -- Main architecture overview
- System Context (C4 Level 1) -- System context diagram
- Compliance Status -- Regulatory compliance tracking