Elixir Phoenix for SaaS Founders

How 37signals spent $3.2 million on AWS in one year and why they decided to leave the cloud entirely—and what this means for your SaaS.

• The $3.2 Million Question
  9 min

  The Day 37signals Shared Their AWS Bill On January 13, 2023, David Heinemeier Hansson (DHH), CTO of 37signals, published a blog post that shook the SaaS industry. He revealed something most companies keep secret: exactly how much they spent on Amazon Web Services in 2022. The number was staggering: $3,201,564. That is $266,797 every month. For context, that is more than most SaaS companies spend on their entire engineering team. And 37signals was already considered efficient at cloud usage. The Breakdown DHH shared the full breakdown of their AWS spend: Their email service HEY alone—one product—consumed $1,066,150 per year. Just HEY's RDS database cost $355,950. Its compute resources (EC2/EKS) cost another $272,359. The Decision 37signals did not publish these numbers to complain. They published them to explain a decision they had already made: they were leaving AWS entirely. "We have made the decision to leave the cloud," DHH wrote. Not just reduce usage. Not optimize costs. Leave. Over six months, they: Leased rack space at two Deft data centers (Ashburn, VA and Chicago, IL) Purchased Dell servers for four 48U cabinets Migrated Basecamp, HEY, and their legacy applications…

Case studies from Discord, Bleacher Report, Supabase, and Pinterest—how they cut infrastructure costs and scaled with smaller teams.

• Who Uses Elixir (And What They Saved) Free with email
  7 min

  Discord: 25 Million Concurrent Users, Under 50 Engineers In 2020, Discord published a blog post that became legendary in the Elixir community. They explained how their real-time messaging infrastructure handled 25 million concurrent users with a team smaller than most Series B startups. The Scale Discord's numbers were staggering: 25 million concurrent users online at peak Millions of messages per second flowing through their system Sub-100ms latency requirements globally Five nines reliability (99.999% uptime) The Team Here is what shocked the industry: Under 50 engineers handling the entire messaging infrastructure No dedicated DevOps army No Kubernetes clusters for their Elixir services No complex cloud orchestration Discord's Elixir services handle their entire real-time platform with minimal operational overhead. When they needed to scale, they added BEAM nodes—not Lambda functions, not API Gateway configurations, not SQS queues. The key insight from their engineering team: "We spend our time building features, not fighting infrastructure." Why Elixir Won Discord started with a mix of Go and Elixir. They migrated to pure Elixir because: *Process isolation: One misbehaving user…

Lessons from Ford vs. Toyota and Southwest Airlines—how manufacturing philosophy explains why some software stacks scale better than others.

• Why Your Programming Language Is a Business Decision Free with email
  6 min

  The Ford vs. Toyota Lesson In the early 1900s, Henry Ford revolutionized manufacturing with the assembly line. His approach was simple: divide work into small, repeatable tasks. One worker puts on the wheel. The next worker puts on the door. The car moves down the line, each step adding another piece. Ford's system was revolutionary. Cars went from luxury items to mass-market products. But the approach had a critical flaw: if one worker made a mistake, the whole line stopped. The system had no resilience built in. Toyota's Innovation In the 1950s, Toyota developed a different approach called the Toyota Production System. Instead of one worker doing one tiny task forever, Toyota trained workers to: Understand the entire process Stop the line when they spotted problems Fix issues immediately rather than passing them downstream Contribute to continuous improvement The result: Toyota became the world's largest automaker. Their cars had fewer defects. Their factories were more efficient. Their workers were more engaged. The Software Parallel Traditional programming languages are like Ford's assembly line: One process handles one task at a time If something breaks, the whole system stops…

Real AWS pricing that explains why per-request billing adds up, and when serverless makes sense—and when it bankrupts you.

• The Serverless Trap Free with email
  9 min

  The Promise That Sounds Too Good to Be True In 2014, Amazon launched AWS Lambda with a compelling pitch: stop managing servers and pay only for what you use. The marketing was seductive. No more provisioning. No more maintenance. Just upload your code and Amazon handles the rest. The pricing model seemed fair: you pay per request, by the millisecond. A thousand requests? Pennies. A million? Maybe a few dollars. For a startup watching every dollar, this felt like freedom. But the reality is more complicated. Serverless is not the cost saver it appears to be. For many SaaS companies, it becomes a trap that adds thousands to their monthly bill while creating operational headaches they never anticipated. What "Serverless" Actually Means Here is the truth the marketing glosses over: serverless still uses servers. You are just renting them by the millisecond instead of by the hour. When you deploy a Lambda function, Amazon spins up a container to run your code. When the request finishes, that container either dies or stays warm for a few minutes in case another request comes in. You are not eliminating infrastructure. You are just changing how you pay for it. The problem is the pricing…

How your programming language choice directly impacts infrastructure costs—and why some stacks require 10x more servers than others.

• The Language Cost Multiplier Free with email
  12 min

  The Assumption That Costs Millions Most SaaS founders choose their tech stack based on what their developers know—or what is popular on Hacker News. They do not realize that this decision locks in infrastructure costs for the life of the company. Your programming language determines: How many servers you need How much memory you require How complex your architecture becomes How many engineers you must hire The difference between an efficient language and an inefficient one is not 20% or 30%. It is often 10x or more. And you pay that multiplier every month, forever. This chapter compares the real infrastructure costs of popular tech stacks. The numbers are based on actual company reports, AWS pricing, and industry benchmarks. The Python Problem: One Worker, Many Tasks Python is the most popular language for web development. It powers Instagram, Dropbox, and countless SaaS companies. But Python has a fundamental limitation that drives up infrastructure costs. The Global Interpreter Lock (GIL) Python can only execute one piece of code at a time per process. Even on a machine with 32 CPU cores, a single Python process uses only one core at a time. Think of it like an office with one…

What you can actually run on a single $5-40/month server—and why some founders never need more.

• The One-Server SaaS Free with email
  8 min

  The $5 Server Myth Cloud providers want you to believe you need their services. They have spent billions on marketing to convince founders that infrastructure is complex, scary, and best left to experts with expensive certifications. The truth is simpler. A single server can handle far more than most founders realize. And when that server costs $5-40 per month instead of $500-1,000, your business model changes completely. This chapter shows what is actually possible on minimal hardware. These are not theoretical limits. These are real numbers from production Elixir applications running today. What One Server Can Actually Do The Hetzner CX11: $4.51 Per Month Hetzner, a German hosting provider, offers the CX11 instance: 2 vCPU cores 4GB RAM 40GB SSD 20TB bandwidth Price: €4.51 (~$4.90) per month On this modest server, a Phoenix application can handle: 2,000-5,000 concurrent users 500-1,000 requests per second WebSocket connections for real-time features Background job processing PostgreSQL database File uploads and storage For a SaaS in the early stages—pre-revenue or just finding product-market fit—this is enough capacity for months or years. The Scale-Up: CPX31 at $14.76 Per Month…

Why Elixir's approach to failure means your customers sleep through outages—and you do too.

• Reliability as a Feature Free with email
  8 min

  The 3 AM Wake-Up Call If you run a SaaS long enough, you will get the call. Or the pager notification. Or the Slack message that makes your stomach drop. "The site is down." In that moment, none of your technical decisions matter except one: how quickly can you fix it? And more importantly, how many customers noticed? Reliability is not a technical vanity metric. It is a business feature. Customers who trust your service stay longer. They pay more. They recommend you to others. Customers who experience downtime churn. They post on Twitter. They switch to competitors. This chapter explains how Elixir makes reliability the default—not something you bolt on later with more infrastructure. The Cost of Downtime Before we discuss solutions, let us understand the problem. Downtime costs money in ways that are easy to calculate and ways that are not. Direct Revenue Loss For e-commerce and transaction-driven SaaS: Amazon: $5,600 per minute of downtime (2018 estimate) Walmart: $13,000 per minute A typical $100K MRR SaaS: $200-400 per hour These numbers scale with revenue. At $1M ARR, an hour of downtime costs $1,000-2,000 in lost transactions. Customer Churn Downtime has a compounding effect…

How Elixir enables smaller teams to punch above their weight—and why your hiring pool might be bigger than you think.

• The Team Size Multiplier Free with email
  6 min

  The WhatsApp Precedent In 2014, Facebook acquired WhatsApp for $19 billion. At the time, the numbers were staggering—not just the price, but what WhatsApp achieved with minimal resources: 450 million monthly active users 32 engineers total (later expanded to ~50) $0 spent on marketing $0 spent on cloud infrastructure (used dedicated servers) While competitors like Skype required hundreds of engineers and massive AWS bills, WhatsApp operated lean. Their secret was not better management or harder-working employees. It was their technology choice: Erlang, the language that Elixir runs on. This chapter explains why your tech stack determines your team size—and why Elixir lets you do more with fewer people. The Full-Stack Reality Modern web development has fragmented into specializations: Traditional Team Structure A typical SaaS team needs: Backend Engineers (2-3) API development Database design Background job processing Integration with external services Salary: $120,000-180,000 each Frontend Engineers (2-3) React/Vue/Angular application State management API integration Build tooling and bundling Salary: $120,000-160,000 each DevOps Engineers (1-2) Kubernetes management CI/CD…

How to understand what Elixir code does without learning to program—and why it matters for your business.

• Reading Elixir Like a Business Document Free with email
  6 min

  Why Founders Should Read Code You will never write Elixir code yourself. That is what you hire developers for. But you should be able to read it. When you can read code: You understand what your team is building You catch mismatches between requirements and implementation You estimate timelines more accurately You evaluate technical hires better You spot red flags before they become disasters The good news: Elixir is designed to be readable. This chapter teaches you to understand it without learning to program. The Pipe Operator: Reading Left to Right The most common pattern in Elixir looks like this: Read it like a business process: Start with a user Pass them to fetchprofile (get their details) Pass the result to validateage (check they're old enough) Pass the result to createaccount (make the account) Pass the result to sendwelcomeemail (notify them) The |> symbol is the "pipe operator." It takes the result of the left side and passes it as the first argument to the right side. Business Parallel: Approval Chains This pattern mirrors business processes: Just as you would not process payment before manager approval, Elixir would not call createaccount before validateage completes.…

Understanding supervision trees, processes, and GenServers—explained through organizational design, not technical jargon.

• The Architecture of Reliability Free with email
  7 min

  Beyond Code: The System That Never Stops In previous chapters, you learned to read Elixir code. Now we explore the architecture beneath the code—the system design that makes Elixir applications so reliable. You do not need to understand the technical details. You need to understand the principles. These principles explain why Elixir applications stay up when others fall down. We will use business analogies throughout. The concepts map directly to organizational design—how good managers build resilient teams. Supervision Trees: The Self-Healing Organization Imagine a call center during peak hours. Calls come in constantly. Agents handle requests. Coordinators manage dispatch. If an agent gets overwhelmed and steps away, what happens? In a poorly managed operation: calls pile up, customers wait, the system breaks down. In a well-managed operation: the supervisor notices, assigns a replacement, and service continues. The Manager That Never Sleeps In Elixir, every process has a manager called a "supervisor." The supervisor: Watches its workers (other processes) Knows how to restart them if they fail Ensures the system continues operating If Engineer 2 calls in sick, the team lead…

How Phoenix LiveView lets one developer build entire features—and why your frontend framework might be unnecessary.

• One Language, Full Stack Free with email
  6 min

  The JavaScript Problem Modern web development split into two separate careers. Backend engineers build APIs. Frontend engineers consume them. They use different languages, different tools, and different mental models. This split created complexity. A simple feature—updating a user profile—now requires: Backend API endpoint (Python/Ruby/Node.js) API documentation Frontend state management Frontend API client Frontend UI components Error handling on both sides Testing on both sides Two engineers. Two codebases. Two deployment pipelines. Two places for bugs to hide. The State Synchronization Nightmare The hardest problem in frontend development is keeping state synchronized: User updates their profile Frontend sends request to backend Backend updates database Backend returns new data Frontend updates local state Frontend re-renders UI Every step can fail. Every edge case needs handling. The result: thousands of lines of code for simple interactions. The Build Tooling Tax Modern frontend requires: npm/yarn for package management Webpack/Vite for bundling Babel for transpilation ESLint for linting TypeScript (optional but recommended) Jest/Vitest for testing Framework…

How Phoenix Contexts keep your codebase organized—and why this matters as your SaaS grows.

• Organized Code That Scales Free with email
  5 min

  The Big Ball of Mud Every successful SaaS faces the same challenge. The codebase grows. Features accumulate. Developers come and go. Eventually, you have what engineers call a "big ball of mud": Code scattered everywhere No clear organization Changes in one place break things elsewhere New developers take months to become productive Bugs hide in the mess The problem is not the technology. It is the structure. Most frameworks give you files and folders but no guidance on how to organize them. Phoenix solves this with Contexts—an architectural pattern that organizes code by business domain. What Is a Context? A Context is a boundary around a business domain. It contains: Data structures (schemas) Business operations (functions) Related logic in one place Think of it like departments in a company: Each department owns its data and operations. Other departments interact through defined interfaces, not by reaching into files they should not touch. Common Contexts in SaaS Accounts Context Handles everything related to users and authentication: Functions you might call: Accounts.registeruser(email: "user@example.com", password: "secret") Accounts.authenticateuser("user@example.com",…

Concrete deployment options for Elixir applications—from $5 VPS to managed platforms, and when to choose each.

• Deployment Without DevOps Free with email
  8 min

  The Deployment Decision Choosing where to deploy your application is a business decision with long-term implications. The right choice depends on: Your stage (pre-revenue vs. growth) Your team's technical capability Your budget constraints Your growth expectations This chapter lays out concrete options for Elixir deployment, from the cheapest VPS to managed platforms. Each option includes real costs, pros, cons, and when to use it. Option 1: VPS (Virtual Private Server) A VPS gives you a dedicated slice of a physical server. You have full control but also full responsibility. Hetzner: The Budget Champion Hetzner, a German provider, offers the best price-to-performance ratio. Bandwidth: 20TB included (more than most SaaS will use) Best for: Bootstrapped SaaS, cost-conscious founders, learning deployments DigitalOcean: The Developer Favorite DigitalOcean is known for simplicity and good documentation. Best for: Developers new to server management, projects needing managed databases Linode (Akamai): The Reliable Alternative Linode offers consistent performance and good support. Best for: Production applications needing reliable support What You Get with a VPS Advantages: Full control…

Where to find Elixir developers, how to train your existing team, and why the talent pool is deeper than you think.

• Hiring for Elixir Free with email
  6 min

  The Talent Myth The most common objection to Elixir: "Nobody knows it. We cannot hire." This belief persists because it seems logical. Fewer developers list Elixir on their resumes compared to Python or JavaScript. Therefore, hiring must be harder. The reality is different. While the applicant pool is smaller, the quality is higher. Elixir developers are self-selected for curiosity, capability, and the desire to work with better tools. And experienced developers learn Elixir quickly—often faster than they would learn a complex JavaScript framework. This chapter explains how to build an Elixir team, whether by hiring specialists or training generalists. Where to Find Elixir Developers Specialized Job Boards Elixir-specific: ElixirForum Jobs: elixirforum.com/c/jobs Elixir Slack #jobs channel: elixir-lang.slack.com Elixir Radar: elixir-radar.com Remote-focused: We Work Remotely: weworkremotely.com RemoteOK: remoteok.com Wellfound (formerly AngelList): wellfound.com General with Elixir filters: LinkedIn (search "Elixir" or "Phoenix Framework") GitHub Jobs (browse Elixir repositories) Community Engagement Elixir has an active, tight-knit community. Engage where developers gather:…

An honest assessment of Elixir's limitations—and when to choose something else.

• When NOT to Use Elixir Free with email
  7 min

  The Honest Assessment This guide has made the case for Elixir. But no technology is right for every situation. Choosing Elixir when it does not fit creates friction, slows development, and wastes resources. This chapter explains when Elixir is the wrong choice. Use it to make an informed decision for your specific situation. CPU-Intensive Number Crunching The Limitation Elixir excels at concurrency—handling many tasks simultaneously. It does not excel at single-threaded computation. The BEAM virtual machine (Elixir's runtime) is optimized for: Many lightweight processes Low-latency message passing Fault tolerance It is not optimized for: Mathematical computation Data processing Machine learning Video encoding The Math A CPU-intensive task in Elixir might run 10-50x slower than the same task in: Rust (fastest) C or C++ Go Java This gap exists because the BEAM trades raw speed for reliability and concurrency. When to Use Something Else Machine learning: Use Python (TensorFlow, PyTorch) or specialized frameworks Video/audio processing: Use FFmpeg, specialized media servers, or Rust Scientific computing: Use Python (NumPy, SciPy), Julia, or C++ Heavy data transformation: Use Go or Rust…