Why Elixir Is the Greatest Language for Constructing a Bootstrapped, B2B SaaS in 2024

I’d wish to share why I selected Elixir because the programming language (and actually, as we’ll talk about, the complete stack) for SleepEasy. I’m going to do my greatest to concentrate on the target options of the language which make it notably appropriate for a small, nimble workforce beginning a software program enterprise.
As a result of SleepEasy is B2B software program, an internet app is completely required. In some unspecified time in the future within the distant future, a cell app could also be too, however I count on to get by with out cell for a very long time. Even when I do someday want a cell app, a easy wrapper round an internet view will in all probability suffice.
The truth that I’m bootstrapping this firm (that’s, self-funding to begin and rising it solely from the enterprise’s personal income) units one different main requirement: the app wants to have the ability to be constructed and maintained by a workforce of 1, no less than for the primary few years or the primary $10k+ in month-to-month income.
Who cares about one-person frameworks?
Have a look at any job posting for a full stack developer and think about simply what number of issues they’re anticipated to have experience in. Each employer is looking for a unicorn who is aware of:

Pictured: A full-stack dev orchestrating two dozen instruments to construct a single internet app
- HTML
- CSS
- Tailwind
- A frontend language (JavaScript/TypeScript)
- A backend language (Ruby, Python, Go, and many others.)
- A frontend framework (React, Vue, and many others.)
- A frontend state administration framework (Redux, Jotai, Vuex, and many others.)
- A backend framework
- REST
- GraphQL
- A SQL database
- A NoSQL database
- A background job system
- An in-memory cache like Redis
- A service crash restoration system (PM2, Upstart, and many others.)
- A message queue (RabbitMQ, Redis, and many others.)
- An online server like Nginx
- Docker
- Kubernetes
- A cloud platform (AWS, GCP, Azure)
- Serverless
- Microservices
- Scaling companies
🥴
It’s an excessive amount of! It’s merely not affordable to count on one individual to have the ability to do all of it. And that’s doubly true for somebody beginning a solo software program firm, the place you’re additionally accountable for buyer growth, advertising, gross sales, and all the opposite components of the enterprise.
All this results in one inescapable conclusion:
We have now to break down the stack!
We have to dramatically reduce down on the variety of completely different applied sciences that you must be taught to construct a best-in-class internet app. That’s the place Elixir (and particularly Elixir plus the Phoenix internet framework) is available in.
How Elixir collapses an internet app’s tech stack
There are three massive methods Elixir helps simplify internet software growth.
- Eradicating layers of the stack completely
- Constructing extra of the stack into both the language, the usual library, or Erlang’s BEAM + OTP platform
- Constructing extra of the stack in instruments you already know
Let me clarify…
Eradicating layers of the stack
Phoenix LiveView has gotten a ton of constructive consideration, and for good purpose. The pitch is you could create wealthy, interactive client-side experiences (similar to a SPA framework like React or Vue) whereas writing simply “backend” code. By constructing on Phoenix’s glorious WebSocket help, LiveView supplies:
- SPA-like web page transitions (i.e., changing simply the components of the web page that change, and not using a full web page reload),
- real-time “reactive” updates of the client-side view as state adjustments on the backend, and
- server interactivity with out ever needing to assemble an API or write JavaScript.
And all of this comes roughly without cost. Seamless, sub-50 ms web page transitions? 0 traces of code. Triggering backend occasions from the from the frontend? 3-4 traces of code. Subscribing the frontend to progress updates on some backend job? 4-6 traces of code.
There are caveats, after all. LiveView has a considerable studying curve by itself, and I wouldn’t advise attempting to construct one thing that’s basically un-document like. (There’s a purpose we constructed Felt as a SPA speaking over WebSockets to our Phoenix backend.) However once more, should you’re constructing a B2B SaaS, 95% of the time the product boils right down to an admin dashboard, a CRUD app, or an ecommerce platform… not the following Figma.
Has LiveView changed 100% of JavaScript for me? In fact not. However fortunately it ships with help for “hooks,” such you could delegate bits of performance to client-side JavaScript (together with SPA frameworks if that’s your factor) whereas holding the remainder of your app in Elixir. After 4 months of growth on SleepEasy’s MVP, I’ve a complete of 16 traces of JavaScript within the challenge.
On high of the concrete advantages of simply needing to grasp fewer applied sciences, it’s exhausting to overstate how good it’s to maintain your head in a single place (the backend, on this case) for the overwhelming majority of the event. Having to consider the interaction between client-side JavaScript, a REST API, and the backend was like sporting a weighted vest since delivery. It wasn’t one thing I thought of as being a drag, however as soon as it was eliminated, it felt like I used to be strolling on air.
Constructing extra of the stack into the platform itself
Elixir has related stack-shrinking advantages past LiveView too. The BEAM and OTP supplies built-in help for lots of concurrency and fault tolerance tooling that needs to be bolted on in different ecosystems.
- Elixir’s fault tolerance primitives (the process isolation and supervision tree model) take away the necessity for crash restoration on the whole-service stage
- Erlang’s ETS tables supply the in-memory caching performance most apps want from Redis, however without having to spin up a separate service (and coping with all of the issues that may go unsuitable in a distributed system like that)
- Phoenix PubSub supplies an in-memory message queue that may substitute one thing like RabbitMQ
- The platform’s considerate design for concurrency prevents any single course of from ravenous the remainder of the system for sources, so you may have hundreds of concurrent requests on a single machine with out worrying about them conflicting with each other.
Constructing extra of the stack utilizing instruments you already know
Lastly, Elixir simplifies purposes by having an ecosystem constructed on tooling you already know. That sounds just a little bizarre, however think about the job queueing system. There are two foremost methods Elixir handles background jobs:
- One is through the use of the BEAM’s built-in, easy concurrency mannequin (often by way of Task or, in a roundabout manner, by way of GenServer)—that is appropriate for any ephemeral duties that don’t should be strong towards server reboots.
- The opposite is utilizing a library known as Oban, which is similar to Ruby’s Sidekiq.
Oban runs on high of Postgres (or SQLite, if that’s your factor), in contrast to Sidekiq and related programs which might be backed by Redis. That reduces the variety of applied sciences that you must be taught (and deploy, and handle!) by one, since presumably you already must know your SQL database.
Elixir has additionally simplified my deployment mannequin this manner. Due to that incredible concurrency mannequin I’ve been happening about, Elixir scales extraordinarily properly as you improve the variety of CPU cores and quantity of RAM on the system. Vertically scaling like that is manner, manner simpler than scaling out to extra machines working your software—or worse, microservices!—since you keep away from introducing distributed programs issues that function a drag on all future growth. It takes zero traces of code change and 0 further testing to pay just a little extra for an even bigger machine… that’s not one thing you may say about scaling out a distributed system! (As an additional benefit, it’s tremendous low-cost to deploy a single monolith speaking to a single database!)
The ultimate space the place the Elixir stack builds extra of the stack in instruments that you just already know is round testing. Whereas ExUnit is superb and I might sing the praises of its readability for days (what number of different ecosystems have your entire group utilizing the testing instrument that ships with the language?), the truth that there’s some unit testing framework in Elixir isn’t that exceptional. What’s superb is the testing story round LiveView.
Bear in mind how LiveView allows you to construct frontend interactivity from the backend? It additionally allows you to write assessments of your frontend interactions in ExUnit, moderately than needing browser automation which is inherently each slower and flakier. You can also make assertions like “once I fill in these type fields and click on this button, I needs to be redirected to a web page with the title of _______.” The price of writing these integration assessments—by way of runtime, growth time, cognitive load, and common pain-in-the-ass issue—is kind of the identical as if I had been testing a pure operate in my enterprise logic, and I discover myself writing manner extra assessments than I ever did for a React SPA. If I’ve to manually take a look at one thing greater than as soon as, you may guess it’s going to change into an integration take a look at.
What’s it add as much as?
Let’s return to the unique checklist of applied sciences a full-stack dev is predicted to know and see what number of of them we will substitute or take away with the Elixir stack I’ve described right here. By my rely, we go from 23 issues an internet app can moderately be anticipated to wish down to eight (counting something constructed into Elixir as one expertise to be taught, and something constructed into Phoenix as one other):
- Elixir (together with supervision bushes for fault tolerance, concurrency primitives like
Activity
, and ETS for caching) - Phoenix (together with LiveView and PubSub)
- Oban for strong background jobs
- Postgres
- The PaaS of your alternative (I choose to self-host with Dokku, a Heroku-like self-hosted PaaS; others choose Render, Fly.io, or Gigalixir)
- HTML
- CSS
- Tailwind
That’s not unhealthy, particularly contemplating you’re in all probability coming into Elixir with possibly half these expertise.
For an entire breakdown of the Elixir ecosystem’s reply to every of the unique checklist of issues a full-stack dev was anticipated to juggle, see the appendix below.
Just a few different accelerators for SaaS startups
Utilizing the stack I’ve laid out above, you would construct 95% of B2B SaaS apps, and you would do it quicker and extra reliably than every other ecosystem I’ve seen. That stated, there are a couple of extra areas of the Elixir ecosystem that make it a terrific match for bootstrapped startups, and I’d be remiss to not spotlight them.
Shopping for a 200 hour head begin
The primary is the Petal Pro framework. “Petal” there’s a reference to the PETAL stack: Phoenix, Elixir, Tailwind, Alpine JS, and LiveView. (It’s a pleasant acronym, however since LiveView launched LiveView.JS
again in 2022, you may deal with purely client-side interactions like toggling visibility of a modal with out the necessity for Alpine in any respect.)
Petal Professional provides you a head begin on implementing an absolute ton of performance that can both be an absolute requirement for each SaaS app, or are extraordinarily good to have for monitoring, debugging, and offering help. I’ve constructed most of those from scratch prior to now, and so they’re all completely doable, however they take time. Having the ability to spend $300 to not have to consider them once more is an absolute steal.
Just a few of the most important time-savers for me:
- Stripe integration for doing subscription billing
- Organizations for customers to group into (together with sending and accepting org invites)
- Admin dashboards (and a toolkit for constructing your personal admin dashboards that lets me churn out new dashboard views in an hour which might have taken me days earlier than)
- Consumer impersonation, in order that when a person studies an issue, I can log in and see precisely what they see
- A properly designed LiveView part library, full with web page layouts, menus, and darkish mode help for the whole lot
Consuming OpenAPI specs with grace
Subsequent, there’s at all times the priority round ecosystem dimension, and it’s true, Elixir’s ecosystem is manner smaller than NPM or PyPI. Now, in follow, I’ve discovered the holes within the bundle ecosystem to not be too unhealthy. In the event you simply want a couple of REST endpoints from a third-party service, it’s not exhausting to put in writing these integration. (I reduce my enamel in C++, although, the place writing your personal implementation for dependencies was not simply inspired, however typically the best path!) However, should you want deep integration with an enormous third get together API, that is likely to be a non-starter.
That’s the place AJ Foster’s open-api-generator
is available in. In contrast to most OpenAPI turbines, it gives a method to do deep customization of the auto-generated code to supply an ergonomic Elixir API. Reasonably than consuming the OpenAPI spec on your third get together and vomiting it out wholesale (resulting in a crummy API {that a} human would by no means produce by hand), the generator provides you methods to:
- Rename parts of the API
- Group schemas into module namespaces
- Merge a number of, nearly-synonymous information constructions into one
- …and way more
You possibly can see examine AJ’s GitHub API wrapper to what you get by default while you spit out the GitHub OpenAPI, and it’s evening and day… and at a scale that an unpaid volunteer might by no means match in the event that they tried to wrap the GitHub API by hand.
AJ gave a terrific discuss eventually 12 months’s ElixirConf exhibiting off the facility of these things:
Maintainability over time
The very last thing I’d like to say is how little or no churn there may be within the Elixir ecosystem. In stark distinction to different stacks I’ve labored in, the place taking even a “patch” replace to a framework can require even consultants to place in hours of irritating debugging (as Gary Bernhardt recently bemoaned), taking an replace to Elixir or Phoenix shouldn’t be a lot of a problem. In the event you’re like me and deal with warnings as errors, you’ll incessantly hit a couple of deprecations and the like, however these are virtually at all times a simple repair. And that’s mirrored in a latest pair of polls I ran. The overwhelming majority of customers are on variations of Elixir and Phoenix launched throughout the final 12 months or so, and fewer than 5% are on variations greater than 3 years outdated.
Elixir and Phoenix worth stability, so it’s typically simple to get entry to new options and not using a bunch of problem.
Wrapping up
I’m not certified to say Elixir is the best language alternative for all apps in all places. I’ve by no means labored in an enormous company, and my expertise with Elixir has been largely targeted on internet and networking. I do really feel snug evaluating it for the challenge I’m engaged on now, although, and for the wants of a one-person growth workforce constructing a B2B SaaS, I don’t see every other stack that provides each the pace of getting began and the power to develop in no matter route your small business takes you.
I’d love to listen to any suggestions you might have—you may attain out to me on Twitter, Mastodon, or electronic mail (my first title at this area).
Appendix: Breakdown of Elixir’s reply for widespread internet dev necessities
Expertise | The standard manner | The Elixir manner I’m advocating |
---|---|---|
HTML | Gotta be taught it | Nonetheless gotta be taught it |
CSS | Gotta be taught it | Sorry, nonetheless gotta be taught it |
Tailwind | Non-compulsory, however good | Non-compulsory, however good |
A frontend language | JavaScript/TypeScript | Phoenix LiveView |
A backend language | Ruby, Python, Go | Elixir |
A frontend framework | React, Vue | Phoenix LiveView |
A frontend state administration framework | Redux, Jotai, Vuex | N/A with LiveView |
A backend framework | Rails, Subsequent.js, Django | Phoenix LiveView |
REST | Wanted for client-server communication | Pointless with LiveView (Phoenix should you want it for product causes) |
GraphQL | Perhaps wanted for client-server communication | Pointless with LiveView (Absinthe should you want it for product causes) |
A SQL database | Postgres, MySQL, SQLite | Postgres |
A NoSQL database | Mongo, CouchDB | Postgres JSONB columns or in-memory caching with ETS |
A background job system | Sidekiq, Celery, BullMQ | Constructed-in Activity or Oban library |
An in-memory cache | Redis | ETS, or a skinny wrapper round ETS like Cachex |
A service crash restoration system | PM2, Upstart | Constructed-in fault restoration by way of Supervisor bushes |
A message queue | RabbitMQ, Redis | Phoenix PubSub |
An online server | Nginx, Apache, Gunicorn | Phoenix |
Containerization | Docker | PaaS like Render, Fly.io, Gigalixir, or Dokku that abstracts over containers (or naked binary launch deployments) |
Container orchestration | Kubernetes | PaaS or naked metallic deployments |
A cloud platform | AWS, GCP, Azure | PaaS or naked metallic deployments |
Serverless | AWS Lambda | Vertically-scaled monolith FLAME if you really want serverless-like scaling or to seamlessly run features on completely different {hardware} |
Microservices | Ache | Monolith with many cores Boundary if that you must guarantee separation of issues between groups |
Scaling companies | Horizontal | Vertical, solely horizontal if you really want redundancy or multi-region deployments |
“The BEAM” is the title of the Erlang digital machine on which Elixir is constructed, and OTP (the “Open Telecom Platform”) is the set of core Erlang abstractions and libraries for issues like course of isolation, networking, and distributed computing.
Phoenix has been ranked the “most liked internet framework” two years working in StackOverflow’s developer survey (2022, 2023).
Admittedly unscientific, however with 200+ respondents to the Elixir ballot and 100+ to the Phoenix model, it looks as if an affordable snapshot of the ecosystem.