Why I Build Everything in Elixir and Phoenix
From MVP to millions of users, Elixir and Phoenix handle it all. In the age of AI, that flexibility matters more than ever.
TL;DR
- One repo, infinite scale. Phoenix gives you a simple monolith that can handle millions of users without architectural rewrites
- MVP in days, not months. LiveView eliminates frontend/backend splits, letting you ship real features fast
- Beyond the web. Nerves lets you deploy to embedded devices, and LiveView Native brings your UI to iOS and Android. Same codebase, same team
- Battle-tested resiliency. Elixir’s actor model was built for telecom; it handles distributed systems and failure gracefully
- Swap dependencies at runtime. In the AI era, you need a stack where changing providers is configuration, not a rewrite
- AI-native architecture. Everything AI tools need to build reliable software is already baked into the platform
Most tech stacks make you choose: move fast now, or scale later. Elixir and Phoenix are the rare exception where you get both.
I’ve built software at Amazon Robotics, where systems talk to thousands of machines simultaneously. I’ve shipped MVPs in days that later handled production traffic from enterprise clients. Every time, I reach for the same stack.
Here’s why.
One Repo That Actually Scales
There’s a persistent myth in software that you need microservices to handle scale. That if you’re serious about growth, you’d better split your codebase into a dozen services from day one.
It’s wrong. And it’s expensive.
Phoenix gives you a monolith that doesn’t fall over. The BEAM (Erlang’s virtual machine) was designed for telecom switches that couldn’t go down. It handles millions of concurrent connections out of the box. Discord runs on it. Pinterest runs on it. Bleacher Report handled 8 million concurrent users during the NBA Finals. On five servers.
You start with one repo, one deployment, one codebase to understand. When you actually need to scale specific pieces, the actor model makes it straightforward. But most projects never get there, and with Elixir, they don’t need to.
From Zero to Production in Days
Here’s what I love about Phoenix: you can build a fully interactive web app without writing a line of JavaScript.
LiveView handles real-time updates, form validation, and interactive UI, all in Elixir. No React. No build pipeline. No API layer between your frontend and backend. Just one language, one mental model, and features that ship fast.
I’ve gone from blank canvas to deployed MVP in 48 hours. Not a prototype. A real application with authentication, real-time features, and production-ready infrastructure. The ecosystem is mature: Ecto for databases, Oban for background jobs, Swoosh for email. You’re not reinventing wheels.
And when your MVP takes off? You don’t throw it away. The same codebase that handled your first 10 users will handle your first million.
One Codebase: Web, Mobile, and Hardware
Here’s where Elixir gets genuinely unique.
Nerves lets you write firmware in Elixir. The same language, the same OTP patterns, deployed to Raspberry Pis, industrial controllers, and custom hardware. I’ve seen teams managing fleets of IoT devices with the same codebase that powers their admin dashboard.
LiveView Native takes it further. Your Phoenix LiveView, the same code that renders your web UI, can render native iOS and Android interfaces. Not a webview wrapper. Actual native components, driven by the same server-side logic.
Most stacks force you to maintain separate codebases for web, mobile, and embedded. Elixir gives you one team, one language, and deployments that span from the browser to the edge device. The operational simplicity is hard to overstate.
Built for Resiliency
Erlang, the language Elixir compiles to, was created by Ericsson for telephone switches. The design requirement was simple: never go down.
That heritage shows. Elixir’s “let it crash” philosophy means individual processes can fail without taking down your system. Supervisors automatically restart failed processes. The actor model isolates failures by default.
If you’re building anything that talks to external systems (IoT devices, third-party APIs, fleet management, payment processors) this matters enormously. Elixir handles unreliable dependencies gracefully because it was designed for a world where dependencies are always unreliable.
I’ve built systems that coordinate hundreds of robots. When one connection drops, the system keeps running. When a message fails, it retries with backoff. This isn’t special code I wrote. It’s how the platform works.
Swap Dependencies Without Surgery
Here’s something that’s become critical in 2026: the ability to change your AI provider without rewriting your application.
Last year you were using OpenAI. This year Anthropic has the best model. Next quarter, who knows? The companies that win are the ones who can switch in an afternoon, not a quarter.
Elixir’s configuration system makes this natural. Runtime configuration means you can change providers, endpoints, and API keys without redeploying. Behaviours (Elixir’s interface pattern) let you define contracts and swap implementations cleanly.
I’ve built applications where switching from one LLM provider to another was a single environment variable change. The business logic stays the same. The tests keep passing. The application doesn’t care where its intelligence comes from.
In the AI era, flexibility isn’t a nice-to-have. It’s survival.
The Stack AI Tools Actually Understand
Here’s something I didn’t expect: Elixir and Phoenix are remarkably well-suited for AI-assisted development.
The functional paradigm means code is predictable. Functions take inputs and return outputs. Side effects are explicit. When an AI tool looks at Elixir code, there’s less hidden state to miss, fewer implicit dependencies to break.
The actor model makes boundaries clear. Each process is isolated. When AI generates code for one part of your system, it’s less likely to break another part.
Phoenix’s conventions are consistent. Contexts for business logic. Controllers for HTTP. LiveView for interactivity. AI tools can learn these patterns and apply them reliably.
I’ve found that AI pair-programming works better in Elixir than in any other stack I’ve used. The guardrails are built into the language.
The Honest Tradeoffs
Elixir isn’t perfect. The hiring pool is smaller than JavaScript or Python. The learning curve for OTP concepts is real. Some libraries you’d find easily in other ecosystems require more work here.
But for the kind of software I build (web applications, real-time systems, anything that needs to stay up) the tradeoffs are worth it. Every time.
What This Means for You
If you’re building something new, consider the total cost. Not just the first version, but the version that handles 10x your current load. The version where you need to swap providers. The version where something breaks at 2 AM.
Elixir and Phoenix aren’t the right choice for every project. But for most of the projects I see (web apps, internal tools, real-time dashboards, API backends) they’re the choice I’d make every time.
And increasingly, they’re the choice that lets AI tools help you build faster without breaking things.
David Kerr is the founder of Kerrberry Systems. He builds custom software for businesses that need it, usually in Elixir and Phoenix. Find him on LinkedIn or GitHub.