So, do you guys do only Ruby for the backend?

So, do you guys do only Ruby for the backend? is a question we get from all potential clients and friends in business quite often. Or worse: are you guys **still* doing only Ruby for the backend*?

The short answer is yes. Ruby is the reason why we're in our third year and stronger than ever. But there are more reasons.

We are currently well on our third year of operations as a Ruby-only development consultancy. Save for one project, we have only used Ruby for the backend of all our projects. But we've got to look into the future, to see if this is sustainable in the years to come.

According to TIOBE, Ruby is still performing well in terms of market, but it is also true that it is not peaking anymore. Check their insights in the TIOBE index for Ruby.

Being a specialised company with only one tech stack has helped us to focus on what matters and to be more proficient in our languages to avoid deviations and bigger projects. The entire backend team knows Ruby perfectly and there are no major differences in their levels of seniority.

Ruby is good for prototyping fast, thus reducing the time to market, it is developer-friendly, ensures clean code (and therefore long-term maintainability for all projects) and most of all, it isn't fragmented: pretty much everyone uses Ruby on Rails as a framework on top of Ruby.

Although our clients most usually hire us to develop their entire product, last year we had a fair share of frontend-only projects, where we coded mostly in HTML/CSS and maybe Angular or Vue.js.

We can simplify our client types in two: those who are technical enough to decide the backend technology, which end up choosing us as experts in Ruby, and those that are either technologically agnostic or just don't know enough about programming languages. For the former, no explanation is needed, and those will always exist, but for the latter, we need to study their cases really well and see if Ruby is a good match for them: if it is not, we will tell them to seek elsewhere for a better match, and if it is, we need to make them understand why is it like this.

When choosing a backend language for our internal projects, it's always Ruby, and it'll be like this for the coming months/years as well. Our websites use Middleman and our internal projects are also coded in Ruby.

We're not in a rush to replace Ruby internally anytime soon. Client-wise, however, might be slightly different.

Allow me to detail it a little bit better.

We're never leaving Ruby behind but we might want to complement it down the road with other backend languages.

I'd like to think that we can actually choose from a set of technologies to use the one that fits the client the best, instead of trying to see if Ruby adapts to that, which is what we're offering now, or having to pass on these deals because they are not a good technological fit.

We've been doing Ruby for three years, and we feel like we could do it for three more years. We're pretty positive that after three years, we will still be doing Ruby in the backend.

However, we don't know where the market is heading to. But we know, and have learnt thus far, that companies normally don't outsource their backend stuff as easily as they outsource mobile or frontend, so the number of backend deals we get is limited.

While going specific and niche did help us until now, and I'm sure it'll do in the coming months/years, I see this interfering with the vision the three MarsBased founders share: grow the company to about 20 or 30 people.

For that, we need to think outside of the box, and that's what we're doing right now: asking hard questions. Is Ruby the only way to go? Do we need to replace it? Can we adopt more backend languages to complement it? Or do we simply need to add other services and just stick with Ruby?

Also, if we grow the team, we can't really expect everyone to know all the technologies, and so, we will have the Ruby team, just as we do have now the backend/frontend teams. Will there be a Node.js team in two years time within MarsBased? Will there be a mobile development team? Everything sounds exciting, but we need to come up with a plan.

Who knows how this company will be in two/three years time? I'm excited to find out how we'll develop from here (no pun intended!)

PS: We happen to be hiring. If you're an Office Manager or a Ruby developer, send your CV to [email protected].