Skip to content

Brainstorm Session 1: Tech Stack Decision

Date: 2026-04-15 Objective: Decide the primary language/framework for the Finnest platform

Techniques Used

  1. Reverse Brainstorming — "How would each stack guarantee failure?"
  2. Six Thinking Hats — Examine from 6 perspectives
  3. SCAMPER — Challenge assumptions about "tech stack decision"

Reverse Brainstorming: How Each Stack Fails

Elixir Fails If...

  1. Can't hire anyone — Australian Elixir pool fits in a room. Project dies if key person unavailable.
  2. IRAP assessor rejects the language — BEAM not on ISM explicit list. Forced to rewrite.
  3. AI tooling falls behind — Smaller corpus means AI productivity gains evaporate past 100K LOC.
  4. LiveView Native never matures — Mobile app needs separate stack anyway.
  5. Library ecosystem gap appears — Critical library doesn't exist, forced into polyglot.
  6. Client's IT can't audit it — Trust erodes when handoff codebase is unfamiliar.

What must be true for Elixir to succeed: - Credible hiring/training story - Pre-validate IRAP language acceptance with assessor - Fallback mobile strategy (not LiveView Native alone) - Accept building more from scratch - Manage client perception of exotic technology

Java/Kotlin Fails If...

  1. Boilerplate drowns velocity — Spring Boot ceremony slows agent iteration. 60% time on framework.
  2. Agents feel bolted on — 3 libraries duct-taped, every agent needs 8 files. "Atomic" degrades.
  3. JVM memory kills operations — 256MB-1GB per service, 8GB+ RAM for dev, slow CI.
  4. Becomes "just another enterprise platform" — Marketing says "AI workforce," architecture says 2015.
  5. KMP mobile has rough edges — Platform-specific code needed for NFC/GPS/push anyway.
  6. Talent pool broad but shallow — Spring Boot devs, not actor-model/AI-agent architects.

What must be true for Java/Kotlin to succeed: - Must use Kotlin (not Java) for conciseness + coroutines - Must adopt Akka/Pekko for actor model - Must resist enterprise over-engineering gravity - Must pair with strong mobile framework

Go Fails If...

  1. No actor model — Agents are ad-hoc goroutines with manual state. Rebuilding OTP poorly.
  2. Error handling exhausting at scale — if err != nil on every line across 200K LOC.
  3. Generics too basic for agent abstractions — Can't build type-safe composable agent framework.
  4. Temporal becomes SPOF — Centralized workflow engine vs OTP's per-process fault tolerance.
  5. No real-time story — Manual WebSockets, need separate frontend framework.
  6. Bland developer experience — Uninspiring for recruiting top talent.

What must be true for Go to succeed: - Accept Temporal as core dependency - Pair with rich frontend framework - Build custom agent abstractions - Be comfortable with explicit verbose style

Six Thinking Hats

White Hat (Facts)

Fact Elixir Java/Kotlin Go
PoC validated? Yes (15/15, 327 tests) No No
ISM memory-safe listed? No (safe by design) Yes Yes
Agent model Native (GenServer) Assembled (Spring AI + Akka) Assembled (goroutines + Temporal)
Fault tolerance Native (OTP supervisors) Library (Resilience4j) External (Temporal, containers)
Real-time Native (LiveView, PubSub) Library Library
Financial precision ex_money (28-digit Decimal) BigDecimal (gold standard) shopspring/decimal
AI dev productivity ~70% of Java ~90% ~80%
Australian hiring pool ~50-100 devs 10,000+ 2,000+
Memory per unit ~1.3KB/process ~256MB/JVM ~4KB/goroutine
Hot code reload Yes No No

Red Hat (Gut Feeling)

Elixir feels right. The PoC wasn't a checkbox — it felt natural. Agents as GenServers, supervision as fault isolation, pipes as pipelines. The architecture IS the language.

Java feels safe but uninspiring. Spring Boot for "AI workforce" is a rocket engine in a minivan.

Go feels like a compromise pleasing nobody.

Black Hat (Risks)

  • Elixir: IRAP acceptance uncertain, hiring pool tiny, ecosystem thin, lower AI assistance quality
  • Java/Kotlin: Enterprise gravity, bolted-on agents, JVM overhead, agent-unfriendly defaults
  • Go: No PoC, no actor model, Temporal dependency, manual everything

Yellow Hat (Benefits)

  • Elixir: PoC proven, native agent model, hot reload, BEAM fault tolerance, elegant pipelines
  • Java/Kotlin: Largest talent, IRAP non-issue, KMP mobile, Spring AI 2.0, maintainable by any acquirer
  • Go: Simple deployment, Temporal workflows, fast compile/startup, ISM-listed

Green Hat (Creative Ideas)

  1. Elixir + Go IRAP boundary — Elixir core, Go for security-critical layer (encryption, audit, access). ISM-listed language where assessor looks, BEAM where the work happens.
  2. Compliance proxy pattern — Go/Rust proxy for defence tenants. IRAP assesses the proxy. Elixir behind it.
  3. MCP at every boundary — Every feature exposes MCP server. Language becomes swappable per domain.
  4. Kotlin + Pekko — Actor model on JVM. Closest to OTP outside BEAM. ISM + hiring + actors.
  5. Design for replaceability — Hexagonal + MCP. Start Elixir, rewrite individual domains if needed.

Blue Hat (Process)

Facts favor Elixir (only proven stack). Feelings favor Elixir. Risks favor Java/Kotlin. Benefits split. Creative ideas mostly resolve Elixir's weaknesses. Elixir's risks are mitigatable; Java's architectural limitations are structural.

SCAMPER

  • Substitute: "One language for everything" → "One language for backbone, other languages for specific capabilities." Actor model + MCP means feature-agents could be any language.
  • Combine: Elixir backend + KMP mobile. Natural split (different deployment targets).
  • Adapt: Assess infrastructure + security controls, not application language. ISM guidance is SHOULD, not MUST.
  • Modify: Hire strong functional programmers (Scala, Haskell, F#) and train on Elixir (2-4 weeks). AI assistance bridges learning curve.
  • Put to other uses: Tech stack as marketing — "Built on telecom-grade OTP (WhatsApp, Discord)" is better than "Built on Spring Boot."
  • Eliminate: Pre-validate IRAP language with assessor. One meeting eliminates #1 risk.
  • Reverse: Define requirements precisely → stack becomes obvious. The requirements describe OTP.

Key Insights

Insight 1: The Requirements Describe OTP

Actor model, supervision trees, fault tolerance as runtime property, hot code reload, feature-level process isolation, pipe-based pipelines, built-in pub/sub — this IS OTP. Every other stack assembles these from 3-5 libraries.

Impact: High | Effort: Medium

Insight 2: IRAP Language Risk is Validatable Before Committing

One pre-engagement meeting with an IRAP assessor resolves the #1 objection. ISM guidance is SHOULD, not MUST. Fallback: Go boundary services for security-critical layer.

Impact: High | Effort: Low (one meeting)

Insight 3: The PoC Already Made the Technical Case

15/15 patterns, 327 tests, 0 failures. No other stack has evidence. Decision has asymmetric information — hard evidence for Elixir, only theory for alternatives.

Impact: High | Effort: N/A (already done)

Insight 4: Hiring Risk Mitigated by AI + Atomic Architecture

AI-assisted development (55% faster, 4:1 ROI) reduces team size. Atomic architecture bounds complexity per feature — don't need deep BEAM expertise for every feature, just core infrastructure.

Impact: Medium | Effort: Low

Insight 5: MCP Makes the Decision Less Permanent

Every domain boundary as MCP server → internal language becomes swappable. Mobile, IRAP, third-party all consume MCP. Domain rewritable in Go/Kotlin without affecting others. "Lock-in" fear overstated when architecture designed for replaceability.

Impact: High | Effort: Medium

Recommendation

Primary stack: Elixir/Phoenix on BEAM/OTP

Risk Mitigation
IRAP language acceptance Pre-validate with assessor. Fallback: Go boundary services.
Hiring pool Hire strong devs, train 2-4 weeks. AI reduces team size.
Ecosystem gaps Build from scratch (HR domain). Accept trade-off.
Mobile Phoenix API + KMP or React Native (not LiveView Native alone).
Client perception "Telecom-grade OTP — WhatsApp and Discord technology."
AI coding quality Improving. Fewer concurrency bugs offset smaller corpus.
Replaceability MCP servers at every domain boundary.

Why not Java/Kotlin: Assembles 3-5 libraries vs inheriting from runtime. For AI-native platform where agents ARE architecture, assembly tax compounds per feature. PoC proved 30-40% less code, zero concurrency bugs, natural agent model.

Why not Go: No actor model, no supervision trees, no real-time. Rebuilding OTP poorly on goroutines. Temporal is excellent but external, not runtime-native.

Bottom line: Elixir is technically correct for this problem. Its risks are mitigatable. The alternatives' architectural limitations are structural and permanent.

Pre-Requisite Actions Before Final Commitment

  1. Engage IRAP assessor — Validate BEAM/Elixir acceptability or confirm boundary pattern
  2. Define MCP contracts for 3 core domains (Scout, Verify, HR) as proof of replaceability
  3. Prototype KMP mobile consuming Phoenix API to validate mobile story

Statistics

  • Total ideas: 24
  • Categories: 5 (Pure Elixir, Elixir+Boundary, Java/Kotlin Enterprise, Hybrid, Risk Mitigation)
  • Key insights: 5
  • Techniques applied: 3

Generated by BMAD Method v6 - Creative Intelligence