Convincing a client to use Phoenix over other popular web frameworks

I’ve recently had a client query our use of Phoenix over other web frameworks. They indicated their investors/mentors had never heard of it and were concerned it wasn’t that popular among devs.

I’m guessing this is mainly a risk mitigation concern and that should they want to find another dev to replace us for any reason, they want to be able to with ease.

I’m just curious how you approach discussions like these with potential clients? Do you have any good resources you turn to that help you convince the client that Phoenix is the better choice over other web frameworks?

We’ve provided something like the following explanation to the client, but would love to hear any thoughts you may have if you’ve had dealing with this/similar scenarios.

Phoenix was created in 2014 (built on top of Elixir, which is the language) and is kind of like a lightweight version of Ruby on Rails. It was recently voted the most loved web framework by developers.

Stack Overflow Developer Survey 2022

Many notable organisations are using Elixir and/or Phoenix, including Apple, Financial Times, Bleacher Report etc… Some benefits of Phoenix are:

  • Easy to learn and quick to scale
  • Enables you to go from prototype to production in no time
  • Incredibly fast
  • Concurrency - can handle lots of simultaneous connections extremely efficiently

It’s better than Java because it allows you to avoid having to use a client side framework like React or Vue. This is thanks to a technology called LiveView, which allows you to write client side behaviour in backend code. The end result is a web application that feels fast like a React app, but doesn’t require the overhead of creating and maintaining separate backend and front end apps.

While not as many developers know it, it is quite easy for other developers to pick up. A ruby or PHP developer should have no problems picking it up in a couple of weeks."


I <3 Phoenix but I think this is a bit misleading. It has the best ratio of like:not-like votes but the total number of votes is quite small compared to the more popular frameworks.


I think your response looks good. I’d add a couple more points:

  1. that it makes modern, real-time features pretty straightforward to add, and give them some examples of what that means to them as a business.
  2. it just runs… fault tolerance due to the backing of the BEAM significantly improves reliability
  3. while developers may have to learn Elixir / Phoenix, they won’t need to learn a bunch of other stuff like external background job managers, redis, latest JS front-end framework, etc as all these things are baked in (@sasajuric’s great talk, Soul of Erlang, (Youtube) tabulates these at the end)
  4. related to the above - it’s operationally very simple to deploy - reduces DevOps costs and skill base required

It is then up to them to weigh up risks and benefits in their context, and I think it’s totally fair if the concerns related to developer availability outweigh the benefits for them - tech isn’t one size fits all. I don’t think you will find a shortage of other clients willing to go with Elixir/Phoenix.


I don’t want to second-guess, but this kind of question feels to me like they don’t really want to be convinced, but really want you to say “OK we will use Rails/Spring”. If there’s more than a little bit of push-back, it’s probably not worth the effort.

1 Like

If non-technical people are concerned about your choice of technology it means they’re worried about painting themselves in a corner. Approaching that would involve figuring out which corner it is they’re worried about and then addressing those worries. I don’t think they want to be convinced about one technology over the other, but they seek ensurance of making a good choice. In the end they’re likely not in the position of properly evaluating the brought up arguments anyways.


I am with @LostKobrakai and @adamu here: pick your battles wisely.

I’ve successfully advocated for Elixir 4 times in the last 6.5 years and the companies told me later they were very happy with their choice. Another 7 opted for something else.

Technical merits don’t matter to managers / business owners; they see technical complexities as your responsibility. They are mostly just managing risk. To them picking a stack with smaller hiring pool is a no-brainer case of high risk.

Whether that means they treat their employees like cattle that can and should be replaced at their whim – I’ll leave that evaluation to you. In my experience this was not always the case but to those people “just treat your people well and they won’t leave, duh!” is somehow not common sense. Then again, people leaving so they can focus on kids or side hobbies is a thing as well so I can understand their point of view somewhat.

If you end up trying to advocate for Elixir, emphasize on the fact that there is a number of companies that chose Elixir without having a single Elixir dev in their team, and still succeeded.

This impresses non-technical people.


I dunno, but if the investor or mentor actually try to have a say in which web framework to use, that feel very micro management to me.I don’t want to be this company’s tech leader.


Yep. It’s none of their business, 98% of the time. You want a problem solved? Cool, I’ll solve it for $X thousand. Let’s go.

I don’t tell my plumber whether to use $0.05 tape or $1.20 one. I want a job well done. If that means I pay a few bucks more I am OK with that.

But then again, they are trying to cover their arse in case you turn out to be irresponsible. They want to be able to call the next guy with minimum friction after, if need be. I understand their plight but they definitely can approach the problem in a more respectful and professional manner compared to what they usually do.

1 Like

Yeah that’s what it sounds like. I don’t think details are what matters, but they hear Tech A all the time, so they’re cautious if they hear Tech B for the first time. If all plumbers you’ve seen bring a wrench I’d also wonder if the next one doesn’t bring one.


The OP mentioned investor and mentor, not founder, CTO or CEO. Using your plumber example, the property investor hired a property manager who in turn hired the plumber. In the most likely event, the investor don’t ever see the plumber. You got to have some trust on the manager you hired, or why bother.

1 Like

Story of all modern IT economy, seriously. You summed it up flawlessly.

Trust is more and more rare to come by these days.

Sadly it’s a mutually feeding phenomena. I had a few contracts where I was treated rather badly and that just made me turn into a guy who shows up to get his salary, do the minimum / recommended amount of work, and then check out. I am not proud of it but employee motivation should be taken more seriously. You cannot be 100% self-motivated; if you go on that end of the spectrum you’re not an employee anymore and you should just pursue your own business ideas.

Thank you for the correction, I got a bit carried away. In this case it’s definitely none of their business what tech stack is being chosen. Or, they just choose fancy terms and they are not actually investor / mentor. In reality they are something much closer to a direct engineering supervisor.


I’ve been able to convince only 1 out of my 13 customers in the last two years to adopt Elixir/OTP. And this just for some minor side project.

They simply don’t want to step out of their mainstream, “well established” stacks. Java, .Net, PhP. :face_vomiting: Nothing else.

  1. while developers may have to learn Elixir / Phoenix, they won’t need to learn a bunch of other stuff like external background job managers, redis, latest JS front-end framework, etc as all these things are baked in (@sasajuric’s great talk, Soul of Erlang, (Youtube) tabulates these at the end)

IMO this is one of the main points that I always choose Elixir/Phoenix instead of another stack, you basically can have everything or almost everything inside your app without needing to use multiple third-party solutions just because of some limitation of the language.

In my experience, the cost savings of doing that is huge in the long run, and I’m not even considering the fact that we also have OTP, immutability, a declarative language, etc. All of this allows you to have a very small team for a relatively complex product and have a very simple and cost-effective deployment.

Right now I’m working on a node.js product, and there is not a single day that I see its code and don’t think “man, this would be so much easier, simpler, and resilient if it was written in Elixir” hahaha :sweat_smile:.

Unfortunately, the issue that I see with this is how to sell that idea, it is hard to get real concrete data to back that claim and a lot of developers and managers (IMO) simply don’t know better and think that having a system that you need to have a huge team and spend a lot of money in maintenance rather than improving the product is basically “how things are”.


Easy for you and me may not translate to easy for them. OOP is probably still the most suitable development paradigm for a team consisted of one or two very good guys and a whole army of junior developers. A lot of teams are like that.


This. Having it all in one package (also literally) saves a lot of money and time. Those can be used for the purpose of business/feature development instead of software development. And that is what matters to managers.

The devs concern can be dampened. Good React + Redux developers will find their way in a Phoenix Live View project quite fast and even faster when they used ImmutableJS. Devs with such background are quite common and they ate used to work with functions we use in the functional world (map, reduce etc). The latest Live View reduced the difference with React even further with declarative assigns. As piping will come to JS in the upcoming years the code will even look more the same.

So even when paradigma’s of JS and Elixir are miles apart, good React devs should be able to switch within reasonable (ROI) time due to similarities in syntax, ‘immutability’ and message passing (state, actions, reducers vs state, events, event handlers)

About ‘popular languages’
and what managers should be informed about in terms of risk.

One of my colleagues is a superb Javascript and Typescript developer. Has fundamental contributions is some libs used by large tech firms (Facebook for example). But he is clear about one thing: the churn in Javascript/Typescript/NPM ecosystem is way too high. The next best framework is always 12 months away (so support for your pick today diminishes after 36 months), populat libs break their API by full overhaul (so you need to rewrite a lot) multiple times in a few years. You almost need one team to develop features and one to maintain the current features (say…webpack…?). Not putting effort in keeping a project aligned with upstream for a few months can be lethal for a project (ROI wise). This colleague is still a JS/TS fan…but it’s his expertise after all.

We have worked for years (and still) with Python. I like the language for it’s easy to digest syntax. But it’s toolchain is rather antique and is has countless quircks. We have the workarounds, they work but they ain’t pretty. It’s eco system also like to break once in a while so you better stay close to recent. It good for a lot, but not so much for realtime apps (GIL didn’t help).

Both JS as Python can do all; and as many people only know Python or JS they make them do all. But that mostly means working with ‘workarounds’. afterthoughts on a fundament not suitable for it.

Java-land I haven’t seen last few years so can’t comment on it.

PHP/Laravel. Around for a long time and a lot of devs. Last year I had a quick look and it was a pleasant surprise as my last view was PHP 4. Seems like a option to consider.

Back to Elixir
While Elixir is quite new, Erlang isn’t!

There is a ‘law’ that says something like: the time a language will survive in the future can be predicted by looking at how long it exists today.

Erlang exists for a looooong time.

The reason Erlang/BEAM (in form of Elixir) rises is because it’s fundament is great for what is needed today. So maybe your best bet is to talk about Erlang and how Whatsapp and some other well known companies use it, and then mention the ‘modern syntax’ version of it like Typescript is a reinvented variant of Javascript (managers don’t need the nuance)

Ps. our greatest devs want composition instead of inheritance, immutability and message passing and less OOP cause of testability. Next project I gonna plug Elixir/Phoenix as it fulfills those wishes by nature. The JS/TS dev I mentioned earlier was already interested as he also saw the benefit of “less distinct moving parts”.


Hmmm, and? I was referring to myself in that paragraph, it is obvious that for other people that may not hold true…

But about the “OOP being the most suitable development paradigm”, personally I can’t agree… It is the most used, that’s for sure, but again, IMO simply because people know no better…

I work in a VC that acquires SaaS products, so we have a huge portfolio of SaaS products that uses a lot of different languages, infrastructures, etc, and from my experience with these products, it is clear to me that products that used a more declarative, functional and immutable language normally needs a smaller team, ship features faster and doesn’t need to spend too much time fixing bugs or fixing regressions.

But that is just my experience, maybe it is the exact opposite for other people, who knows :man_shrugging:


I agree with you, for a small to medium sized and motivated team, functional programming is often more productive.

For large team that have very diverse skill level, especially if most are at the lower end of the spectrum though, a code base in a stricter hierarchy with lots of boiler plate might be better, a la java. At least some people believe so,

Of course, many teams are led by people who think they are super good but not really so. Then it will be a recipe of a big mess.


I’m with @LostKobrakai. They basically want to know that they don’t get stuck with some technology nobody uses, doesn’t want to use or can’t maintain in the future. Besides, if they haven’t heard of Phoenix they most likely don’t know anything about Elixir either. That explanation won’t help to convince a client because it doesn’t address any of their real concerns (risk/cost/people).

Even it was a technology question, I’d be careful using generic statements like in that explanation. There’s nothing project specific in there. No reason why it’s better for the projects you’d be working on and why it would benefit them. Basically everything can be said about other languages/frameworks.

Let’s look at the statements.

Easy to learn:
There are already a lot of java/vue/react/… developers that we can hire. Why should they learn something new at all?

From prototype to production in no time:
This will only be the case for really small projects. And those can be done with just about any technology.

Incredibly fast:
In most projects the language/framework choice isn’t the bottleneck when it comes to performance. And how much faster is it? Do we benefit from it? Aren’t other languages faster?

Java/Go/…/… handle lots of connections as well. What makes this special?

“it’s better than Java because”…try not to say things like that. It will only cause bad reactions from people who like Java/React/Vue.

While LiveView is great, there are also other things to consider. Lack of component libraries like in Vue/React so you might have to write many yourself. In many cases you still need developers who know what they are doing when it comes to frontend (js/html/css/UX/accessibility). A lot of backend developers aren’t very proficient in those things. LiveView is also stateful. This means your deployments will be different. Form handling is still being worked on since it’s still based on stateless so if you have lots of complex forms that might be an issue. Replacing frontend/backend ‘specialists’ with full-stack developers can be a bad idea depending on the situation.

So the explanation doesn’t address any business concerns and it doesn’t convince me as a developer either. All I read are risks (not many people know it, new way of working) and no reasons why those risks are worth it. And depending on the project requirements Elixir/Phoenix could actually be a bad fit.


I think we’re in agreement here, but the tech leader should, IMO, be happy to justify, in detail, their choice of web framework or any significant technology choice to a mentor or investor and how it aligns with the budget and the nature of risk the organisation is willing to take on. Here’s what has shaped my opinion…

I’ve been a developer, tech lead, business founder, investor and business advisor (mostly in software technology for heavy industry), and I have seen multiple major car crashes from very smart tech leaders resulting in zero feature delivery for 18+ months 3-4 years down the track. (All due to overcomplicating things FWIW.)

I would absolutely be wanting a very robust discussion with any tech leader on the architectural and philosophical approaches they choose to take (particularly if I didn’t directly hire them), as poor choices can break the company.

That’s not to say I would impose my preferred tech stack on a tech leader - I don’t and I wouldn’t - but I do want to ensure they can explain the long-term consequences of their decision-making. The role of a mentor/investor/company director in this case is not to micro-manage, but to ask the hard questions of how things look 5 years down the track, what does the total cost of ownership look like and what drives it, how the understanding of the system will be maintained in corporate memory, how is complexity assessed, what range of support skills will be required, how developers will be onboarded, what is the level and nature of vendor lock-in, what kind of trade-off analysis is performed when pulling in dependencies, compliance with regulatory obligations, what level of independent thought has been exercised vs doing whatever FB & Google do with their multi-$B R&D budgets, etc. The framing of questions would obviously change depending on the context of the company.

If this is done in the right way, with mutual respect etc etc, it is the way to build two-way trust and understanding. You don’t just hire a manager and immediately totally trust them - that’s not how it works unless you have worked with them already for a number of years. And as a newly hired manager, you don’t just “know” what’s important to a particular company - going through the process of justifying and refining is part of the process of learning what’s important (and also whether the owners are generally sensible or not and whether you want to hang around :slight_smile: )

There is a difference between supervision and oversight. And from an oversight perspective, it is their business to understand potential risks and costs introduced by a particular tech stack. As a common example, if you are raising funds in a public market, you must disclose potential risks specific to your company. This is definitely a board level and investor concern. Here’s an extract from the prospectus for a recent-ish software IPO (ASX:ICR). Vendor lock-in to Azure, a tech-stack decision, gets a special mention:

Investors require oversight (either directly for small companies or through a board of directors for large companies). For tech companies, this means satisfying themselves that the tech decision-making is in the interests of the shareholders and other stakeholders, and that means having these robust discussions with the individuals tasked with the decision-making. Directors leave themselves open to legal action from investors if they can not demonstrate that they have taken reasonable steps to manage key risks to the organisation, or if the risk profile of the organisation is materially different to that previously communicated to investors.

It’s no different to other roles - directors directly engage with the CFO to understand the risks & controls in place, and engage external auditors in addition to ensure the CFO or their regional representatives aren’t redirecting tax office payments into their personal accounts (or whatever else). And yes, they may tread on toes - e.g. pushing the CFO to implement a compliance system. They engage with the CMO to understand the marketing programme and often-times ask the next level down to explain how marketing spend represents value-for-money. They engage with the CPO and individual product managers to check-in on the implementation of product strategy. Internal control models (e.g. as described in Sarbanes-Oxley) encourage directors to regularly receive information from individuals below executive management levels to ensure an unrealistically rosy picture is not being painted by the execs.

People’s personal circumstances can drive them to do things that they may not do otherwise (e.g. a life event leading to well-hidden drug or alcohol addiction which then impairs the clarity of their thinking - maybe it’s just Australia, but I’ve seen this 3-4 times now), so this oversight, while more intense up front, does need to be ongoing.

Finally, for me personally, when I am in a tech leadership role there is nothing more demoralising than zero interest in tech strategy & approach from up on high.

Well this turned into a bit of an essay! Hopefully it’s useful.


While I don’t disagree with your analysis on a high level, it’s a bit one-sided. I and many others here have the history of objectively reducing expense of companies who were initially stubborn to adopt Elixir.

A lot more pages can be written about the benefits of a technology that’s explicitly made with the purpose to be quick to learn and achieve productivity with but when all the chips are down what truly matters is: have you contributed to the business’ bottom line?

And yes, yes I have, just by practically rewriting parts of their apps in Elixir and showing that it is objectively improving the entire status quo (vs. an Rails or Node.JS app).

Using your logic is the perfect way to never let any innovation flourish. There are objective, technical, often financial, and easy-to-write-down-in-a-report reasons about why is Elixir superior to e.g. Python, JS, Ruby on Rails, provided a few assumptions are correct (like: you don’t have to keep 50 devs busy to fill a budget which is sadly also a thing).

That somebody is not willing to see nuance and just puts aside the more recent thing because they don’t want to change the way they were doing stuff is fair; it’s their right and their prerogative. That doesn’t however mean they’re not missing out on legitimate benefits.

They chose to stick to their (previous) guns. That’s not the same as “the new guns are not that good”.