OTP as Primary Stack¶

Status: Accepted Date: 2026-04-16 Decision Makers: Gautham Chellappa Supersedes: None Related: ADR-0011 (Elixir/Phoenix Migration — the AgenticAI-era decision this formalises for Finnest)

Context¶

Finnest is the clean-sheet platform that succeeds the AgenticAI-app Laravel codebase. ADR-0011 established the AgenticAI → Finnest migration and chose Elixir/Phoenix as the target stack. Finnest-specific brainstorm-01 re-validated the decision against the broader Finnest scope (19 modules, 365 features, dual commercial + IRAP deployment, multi-industry).

The question for this ADR: do we formally adopt Elixir/Phoenix on BEAM/OTP as the primary stack for Finnest, given the broader scope?

Decision¶

Yes. Elixir 1.17+ on OTP 27+ with Phoenix 1.8+ and LiveView is the primary application stack for Finnest. Flutter is the companion mobile stack (ADR-008-F). Go is used only for the IRAP boundary proxy (ADR-007-F).

Alternatives Considered¶

Stack	Rejected because
Java/Kotlin + Spring Boot / Akka-Pekko	Assembly tax for the agent model (Spring AI + Akka + separate real-time lib = 3 libraries duct-taped); enterprise gravity; JVM memory overhead; fourth language for mobile anyway
Go + Temporal	No native actor model; Temporal is a SPOF external to application; rebuilding OTP poorly on goroutines; bland developer experience
TypeScript / Next.js	Single-threaded event loop (architectural, permanent); no native supervision; PM2/K8s are external assembly
Python / FastAPI	No built-in UI framework → always two-language stack; weaker concurrency story for agent swarm
Rust / Axum	Borrow checker confuses LLMs → 3–5× slower AI-assisted development velocity; overkill for CRUD-heavy domain

See ../brainstorms/brainstorm-01-tech-stack-decision.md for full analysis (Six Hats, Reverse Brainstorm, SCAMPER).

Consequences¶

Positive:

Native agent-swarm architecture (GenServer = agent; supervisor tree = fault isolation; message passing = coordination)
LiveView handles three UI modes (structured screens, agent-composed views, autonomous inbox) without a JS framework
Pure function pipelines for payroll / financial calculations — deterministic, auditable, testable in isolation
Per-process fault isolation means one bad record doesn't crash bulk operations
Pattern matching provides exhaustive compliance rule dispatch with compiler warnings on missing cases
Hot code reload — deploy new agent logic without dropping connections
No future re-platforming needed — the agent runtime IS the application runtime

Negative:

Smaller Australian hiring pool (~50–100 Elixir devs vs 10,000+ Java/Kotlin)
~30% less effective AI-assisted development than TypeScript/Python today (improving over time)
Thinner package ecosystem — some Laravel conveniences require manual implementation
Functional programming learning curve (front-loaded; ~1 week to productive)

Risk mitigations:

Hiring: strong functional devs (Scala/Haskell/F#) cross-train on Elixir in 2-4 weeks; AI bridges knowledge gaps; atomic architecture bounds per-feature complexity
IRAP language acceptance: ADR-007-F (three-layer with Go boundary proxy) addresses this
Ecosystem gaps: core deps identified upfront (Oban, Ueberauth, ExAws, Guardian equivalents); thin HTTP wrappers for AI APIs
MCP at every domain boundary (ADR-004-F) makes any domain rewritable in another language — no permanent lock-in

Tipping points for re-evaluation:

AI SDK ecosystem for Elixir fails to materialise within 12 months (unlikely — it's progressing)
LiveView proves insufficient for agent-composed UI mode at production scale (early validation during Phase 0)

Relationship to Guardrails¶

Enforces: AR-03 (OTP app structure), AR-09 (LiveView only on web), AR-10 (phx.gen.auth), AR-11 (Oban over SQS), AR-13 (standard PostgreSQL).