So recently I received some advice from a technical VC to the effect of, "it's better to hear a project is built in an esoteric technology like Elixir than a more popular technology like Ruby on Rails where it is easy for a competitor to replicate the product." This is some rather misguided advice on many levels, the most obvious being that Elixir and its popular framework Phoenix are in fact Ruby and Rails inspired (to the point that a former Rails contributor created the latter). But besides that more nuanced technical point, this is an interesting idea, that somehow using a framework that makes development easy, also makes your product easy to copy.
Let's imagine a scenario for a moment where I take this advice whole hog. I decide that I want to make my software even harder to copy so I decide to go ahead and build from scratch in let's say Crystal. It's new, its ruby-like, and super fast. There's few libraries or frameworks for it and a tiny community around it. It takes me a few months longer than normal to build because I have to build a number of integrations with different services that don't exist yet. I even go ahead and choose an esoteric frontend to boot because why stop at having a unique backend. We build the frontend in Elm, which is a really awesome language, and also not incredibly popular. So now we have our esoteric stack that not many developers actually know and it would take a ton of time for a competitor to copy it when looking at the source code.
But wait. Nobody can actually see my source code anyway. Well maybe they can see the compiled client side code, but in actuality when people copy products they aren't viewing the source code at all. They take a look at what you've built and say "hey, I can make this with insert technology I already know here." So now someone loves what we've built and they go I'm going to make that same thing in Ruby on Rails. Since Ruby on Rails has tons of existing integrations and libraries they make quick work out of all that core crap like authentication and database modeling that we had to build ourselves. Suddenly, three months later, we have a competitor on our hands.
As time goes on we are going toe to toe on features but over time they are able to release features that customers demand faster and faster. Our customers start to feel like they are getting a bad deal and move over to the competitor. Six months later we are dead.
It turns out that it really doesn't matter what technology you choose to build your software in (for the most part) as long as it gets the job done well. We got outpaced by someone that chose a popular, boring, old framework like Ruby on Rails because they were able to leverage years of community work to abstract away all the boring core things that all web applications need. In the end the users really do not care what technology you use to build things under the hood, just as long it is reliable and meets their needs. When building something new, your MVP rarely is going to meet every need at the start. Your customers are betting that you will continue to build on the solution to get there. If you aren't able to do that first, then they will leave for someone that is providing more value for the money faster. This is why frameworks are so important and why they are so popular amongst startups.
Ruby on Rails is not my preferred stack, but I have immense respect for the framework that helped build Github, AirBnB, Basecamp, Shopify, Twitter (at first), and Stripe. You should first and foremost choose a technology based on your comfort level with it. Paul Graham famously built Viaweb in Common Lisp, an esoteric choice at the time, but he was productive with it and thus successful. Even when DHH himself went on to build the first version of Basecamp with Ruby it was an esoteric choice. There was no Ruby on Rails yet but he found himself immensely more productive in Ruby and thus was able to ship an awesome product. A byproduct of which is Ruby on Rails, one of the most successful web frameworks of all time.
There are many reasons to choose one stack over another, but the ability of a competitor to replicate your product easily is not one of them. The only thing that matters is how easily can YOU build your product.
Let's imagine a scenario for a moment where I take this advice whole hog. I decide that I want to make my software even harder to copy so I decide to go ahead and build from scratch in let's say Crystal. It's new, its ruby-like, and super fast. There's few libraries or frameworks for it and a tiny community around it. It takes me a few months longer than normal to build because I have to build a number of integrations with different services that don't exist yet. I even go ahead and choose an esoteric frontend to boot because why stop at having a unique backend. We build the frontend in Elm, which is a really awesome language, and also not incredibly popular. So now we have our esoteric stack that not many developers actually know and it would take a ton of time for a competitor to copy it when looking at the source code.
But wait. Nobody can actually see my source code anyway. Well maybe they can see the compiled client side code, but in actuality when people copy products they aren't viewing the source code at all. They take a look at what you've built and say "hey, I can make this with insert technology I already know here." So now someone loves what we've built and they go I'm going to make that same thing in Ruby on Rails. Since Ruby on Rails has tons of existing integrations and libraries they make quick work out of all that core crap like authentication and database modeling that we had to build ourselves. Suddenly, three months later, we have a competitor on our hands.
As time goes on we are going toe to toe on features but over time they are able to release features that customers demand faster and faster. Our customers start to feel like they are getting a bad deal and move over to the competitor. Six months later we are dead.
It turns out that it really doesn't matter what technology you choose to build your software in (for the most part) as long as it gets the job done well. We got outpaced by someone that chose a popular, boring, old framework like Ruby on Rails because they were able to leverage years of community work to abstract away all the boring core things that all web applications need. In the end the users really do not care what technology you use to build things under the hood, just as long it is reliable and meets their needs. When building something new, your MVP rarely is going to meet every need at the start. Your customers are betting that you will continue to build on the solution to get there. If you aren't able to do that first, then they will leave for someone that is providing more value for the money faster. This is why frameworks are so important and why they are so popular amongst startups.
Ruby on Rails is not my preferred stack, but I have immense respect for the framework that helped build Github, AirBnB, Basecamp, Shopify, Twitter (at first), and Stripe. You should first and foremost choose a technology based on your comfort level with it. Paul Graham famously built Viaweb in Common Lisp, an esoteric choice at the time, but he was productive with it and thus successful. Even when DHH himself went on to build the first version of Basecamp with Ruby it was an esoteric choice. There was no Ruby on Rails yet but he found himself immensely more productive in Ruby and thus was able to ship an awesome product. A byproduct of which is Ruby on Rails, one of the most successful web frameworks of all time.
There are many reasons to choose one stack over another, but the ability of a competitor to replicate your product easily is not one of them. The only thing that matters is how easily can YOU build your product.
Michael Rispoli
Software Engineer & Creative Technologist
Software Engineer & Creative Technologist