Context
Two distinct account-end states need design: (1) operational suspension (non-payment, AUP violation); (2) user-requested deletion for GDPR compliance. These are separate mechanisms, not a choice between them.
Decision
- Soft-suspend for operational suspension (non-payment after dunning, AUP violation, chargeback freeze). Account is blocked, all data retained, can be reactivated. No data deleted.
- Hard-delete request flow for GDPR Art. 17 right to erasure. User submits a deletion request; we permanently delete all their data. Iteration 1: manual process (user emails, we execute). Self-serve hard-delete button comes in Iteration 2.
Alternatives Considered
- Hard-delete only (no soft-suspend) — loses the ability to reactivate lapsed customers. Rejected.
- Soft-suspend only (no hard-delete) — violates GDPR Art. 17. Not legally permissible. Rejected.
- Self-serve hard-delete at launch — adds build complexity before we have volume. Rejected for Iteration 1; deferred to Iteration 2.
Consequences
- Soft-suspend is the default end-state for any automated lifecycle event (payment failure, trial expiry, AUP violation).
- Hard-delete path must exist at launch for GDPR compliance, even as a manual flow. Document in Privacy Policy (§ data subject rights) and ToS.
- ToS §4.3 already includes suspension-without-refund for AUP violations. Consistent with this model.
- When building Phase 1.5 (billing) and Phase 1.9 (operator dashboard): implement suspend/reactivate controls; flag hard-delete as "request only" in the UI until Iteration 2.
Revisit trigger
Iteration 2 — add self-serve account deletion UI. Revisit if GDPR enforcement guidance changes the acceptable timeline for processing erasure requests.