Our stack: Ruby, Elixir, Python — and when each one wins
Most “what stack should we use?” debates are really arguments about taste dressed up as engineering. We try to keep it honest: pick the language that fits the shape of the problem, and don’t reach for a heavier tool until the problem actually demands it. In practice that lands on three.
Ruby — the default, and our favourite
Ruby is where we start, and for most startups it’s where we stay. Rails lets a small team move at a speed that feels unfair: a single engineer can carry a real product — auth, payments, background jobs, admin, the lot — and the framework’s conventions mean the next person can read it without a tour.
Ruby wins when the hard part of your product is the product, not the infrastructure underneath it. If you’re not doing genuinely complex AI work, and you’re not running heavy data-analytics workloads against your database, Ruby’s productivity is almost impossible to beat. It’s the most boring-in-the-best-way choice we make, and it’s the right one far more often than the internet would have you believe.
Elixir — when failure is expected and that’s fine
Some systems are built on the assumption that individual operations will fail — connections drop, messages get lost, a process dies — and the right response isn’t to prevent every failure but to make it a non-event. That’s Elixir’s home turf.
On a system like Guardian, where things are expected to break at the edges, the let-it-crash model earns its place: supervision trees restart what died, the rest of the system never notices, and you get resilience and massive concurrency without heroics. When uptime under messy, unpredictable load is the whole point, Elixir is worth the smaller ecosystem and the team ramp.
You don’t reach for it because it’s elegant. You reach for it when “this part will fail and the system must shrug it off” is a core requirement rather than an edge case.
Python — when AI is the core
If artificial intelligence isn’t a feature bolted on the side but the core of what you’re building, there’s no real debate: it’s Python. The models, the libraries, the tooling, the examples, the people — they all live there. Fighting that to stay in your favourite language is a tax you pay on every line.
So we don’t fight it. When AI is the centre of gravity, the work goes to Python, and the rest of the system talks to it across a clean boundary.
The actual rule
There isn’t a best language. There’s a best fit. Ruby for shipping products fast and keeping them readable. Elixir when failure is part of the design. Python when AI is the job itself. Most of the skill is knowing which problem you actually have — and resisting the urge to use the exciting tool on a problem that didn’t need it.