Skip to main content

ADR-0001: Two Device Types; the App Is Not a Device

Status

Accepted

Context

Azan360 needed a device-management model covering both sold hardware (transmitters, stream players) and the free mobile app. Conflating the app with physical devices would tie every free-tier user to inventory tracking and Super Admin approval — machinery that exists to gate paid, sold hardware, not app installs.

Decision

Exactly two physical, sold device types — transmitter and stream player — live in the devices table, gated by an identical Super Admin approval lifecycle. The mobile app is a separate, free entity (app_installs), gated only by mosque membership, never by inventory or device approval.

Alternatives Considered

Not recorded in source material.

Consequences

  • The free tier is never blocked by hardware supply, approval queues, or inventory logistics — installing the app requires nothing but joining a mosque.
  • Every place in the system that reasons about "a device" can assume it means sold, inventory-tracked hardware; app installs are handled through a distinctly separate code path (app_installs) rather than a device subtype, avoiding special-casing throughout device logic.
  • Any future feature that wants to treat an app install like a device (e.g. for a unified fleet view) has to explicitly bridge the two models — they don't share a lifecycle by default.