The suitability of Ruby for startups and one-person teams

Hey friends,

I have an opportunity to write about the suitability of Ruby for startups and one-person teams.

Would you be kind enough to share how Ruby has given you the edge over other languages/ ecosystems? DMs also appreciated :envelope_with_arrow:

TIA :pray:t6:

I think 90% of what makes Rails special is the people involved – the ethos of how they interact. The useful win-win style functionality that emerges when multiple partially dysfunctional people get together and want to put together something meaningful – that is to all go in a similar direction. Let me elaborate a little on that last idea.

Nothing truly useful in Rails comes about solely based on one person’s effort. Some things might look like a “one man band” kind of situation, but really that busy person doing the leg-work is all the while keenly focused on how others are using their shiny new thing. Intensely observant about how their effort is being received. In a selfless kind of way they hope to maximise the productivity for those willing to take their product out for a spin. And the one on the receiving end, leveraging that code, can often recognise that some real blood, sweat, and tears has gone into crafting the thing. That’s win-win because the person building is mostly hoping that people will love their creation, and the one utilising is dearly thankful for the efforts that have resulted in things coming together.

While this also happens certainly in other communities, it’s the lower barriers between Rails people that allow this ecosystem to shine. We might not have a technically perfect language that we write with – and that is okay because the core Matz idea of “programmer happiness” is much more important than having a perfect language. We simply have lower barriers between people, and then big things can happen due to the sheer respect that folks have in this community. It is a safe and welcoming place, and people love it.

I say all of this because in other circles folks are eager to look for “the latest new thing” and run off to do that instead of the current tech. And with Ruby folks even though we might have gone a few different directions, for instance over the past few years in regards to front-end javascript framework things – let’s do webpacker – let’s not do webpacker, etc, for those that have committed and said, “it’s cool – I’m not trying to run off and leave this place just over a front end thing – after all the world at large can’t choose how to do front end stuff either”, then we are all here and contribute, and are willing to all be wrong together sometimes, and also all be right together as well. We can be unified, and gravitate towards having overall consistency in place.

Compare that with Microsoft who is constantly trying to mirror other technologies. If it were a person, they would be diagnosed with a cluster B personality disorder. They’re all over the place trying to please everyone. Look at the weirdness of how the Entity Framework has evolved over there – largely just trying to emulate what Rails does, but never getting it “right” because the ecosystem does not encourage people to be in it for the love of the game, but rather just be in it to consume and discard, expecting some new thing to come around the corner. It’s why their whole tablet thing had miserably failed – “hey everyone let’s ditch the keyboard and go to a touch interface” just trying to be some new thing. No, real people want to hang in there and simply work together with known good stuff.

Rails is a group of people hanging in there and loving it, working with “known good stuff”. Trusting that even if we’re all wrong for a little while, we won’t all be wrong forever, and it’s fine to be together and all contribute as a group.

No person is an island in the Rails community. We are in this for the love of the game.


In my experience, the advantage Rails gives to a single dev is simply not requiring choices before you deliver value. You don’t need to decide on which ORM, routing layer, JavaScript bundler (almost, on this one), template language, testing framework, or runtime. The defaults C-Ruby/Rails provides for each of these can take you far.

Some other frameworks go even farther, offering authn/authz, background tasks, etc, but those are under a day of effort each to get set up in a Rails app; hours for those experienced with the gems. I consider that close enough. You can go even faster by picking up one of the Rails app templates, like Jumpstart. I prefer to stick to defaults, tack on SimpleCSS to make it look good, and start delivering features.

Basically, Rails enables you to get down to writing business logic within minutes for experienced devs, or a few days for less experienced devs. If you have internal stakeholders, you can get into your iteration cycle with them faster, allowing you to deliver real value.

As the app grows, you may migrate away from some of the Rails defaults, but those defaults seldom get in the way. You shouldn’t find yourself reaching for a rewrite because the “defaults” no longer make business sense. However, you may find some pain if you swap pieces out (partials to Components comes to mind), but the app itself will be viable, hopefully well past the time a single dev can keep up with business demands.

That, at least, was my experience of being a solo dev for 18 years in small business.

Hope that helps, -Jack


Hi Lorin,

Thank you for such a comprehensive response.

I am in agreement with you, especially when it comes to the sense of community within the Rails fraternity. Bring fairly new to the community myself, I have already experienced a lot of generosity from other members.

Also, +1 regarding the stability of Rails that comes with sticking to tried and true ideas.

For example, some engineers who have worked on microservices have spoken about returning to monoliths for various (plausible) reasons.

Of course, each approach has benefits depending on context.

It stands to reason that the best choice would boil down to picking the right tool for the right job and not necessarily being lured one way by hype.


As a former .NET developer, I totally agree.

1 Like