Ruby on Rails used to be the hot band everyone wanted to see live. Now it feels more like a cult classic, still good, still playing, but to a smaller, more devoted crowd. And lately, some folks are wondering: is Rails on the path to becoming the next COBOL?

Yes, that COBOL. The 65-year-old language quietly running billions of lines of code inside banks, governments, and systems nobody wants to touch but everybody needs. On paper, the comparison seems extreme. But look closer, and you’ll start to see the shape of a long tail forming behind Rails. One that looks suspiciously like legacy.

Let’s dig in.

COBOL and Ruby on Rails couldn’t be more different in syntax, style, or era. They definitely share one thing though: both were once the default choice for a generation of developers.

COBOL, born in 1959, became the backbone of enterprise and government systems by the ’70s. If you’ve ever withdrawn cash, paid taxes, or waited for a check to clear, COBOL probably had something to do with it. Its dominance was complete, and it stuck — not because developers loved it, but because rewriting working software is expensive, risky, and often unnecessary.

Fast forward to the 2000s. Enter Rails: elegant, opinionated, and built for speed. DHH dropped convention over configuration like a mic, and the web dev world listened.

From 2005 to 2014, Rails was the framework of choice for startups, SaaS tools, and hacker weekends. Twitter, GitHub, Shopify, and Basecamp all bet big on it. For a while, every bootcamp taught it, every founder loved it, and every developer blog had a hot take on ActiveRecord callbacks.

It was a golden era. Until it wasn’t.

Spoiler alert: not like it used to.

Once the backbone of every hot startup stack, Rails has quietly slipped from the spotlight over the past decade. While direct stats about framework usage can be hard to pin down, Ruby’s trajectory helps illustrate the shift. GitHub’s Octoverse reports show Ruby falling from #5 (2014) to #10 (2022) in language rankings. The TIOBE Index recently pushed it to 24th, with its CEO bluntly suggesting Ruby is “likely to go out of fashion.” Ouch.

Community chatter reflects the mood. “Rails is just not what it once was,” wrote one long-time Redditor. “The amount of jobs are way down and the pay is too.” Another chimed in: “It’s not COBOL — nothing that critical was written in it. Rails will eventually die.”

But not everyone’s buying the obituary. Rails defenders argue it’s simply matured. It might no longer be trendy, but it’s still incredibly efficient. It does what it promises. It allows small teams to build and ship real products fast, without the overhead of piecing together half a dozen libraries. In an era where VC money is drying up and lean teams are the norm, that’s a value prop worth paying attention to.

We see this play out with companies we work with, many of which are organizations that run massive products on large Rails codebases. One client, with a market cap north of $2 billion, has definitely felt the pull to rebuild in something “modern.” But when it comes to cost and risk, the appeal fades fast. Some functionality is being moved to other stacks where it makes sense, but the core will likely stay on Rails for years. There’s simply no silver bullet waiting on the other side.

To understand where Rails might be headed, it’s worth studying COBOL’s fate.

COBOL hasn’t been hot in decades, yet as of 2017, 220 billion lines of it still powered key systems. Some estimates say 43% of banking platforms and 95% of ATM swipes involve COBOL code. Why? Because rewriting complex financial logic that’s business-critical (and often undocumented) is risky and expensive.

The kicker? Most COBOL developers are nearing retirement. In 2020, some U.S. states literally had to beg for COBOL engineers to fix outdated unemployment systems. And those engineers? They’re making bank.

COBOL is a classic case of technological inertia. As a consequence, it’s created a niche economy where a small number of specialists quietly hold the keys to critical systems. And they command serious salaries for doing so.

Just to be clear: Rails isn’t COBOL. But the trajectory? It rhymes.

Many foundational platforms still run on Rails. Shopify’s massive monolith? Rails. GitHub? Rails. Basecamp? Rails, obviously. These companies aren’t rushing to rewrite their cores in Elixir or Go. Instead, they’re optimizing what works — and contributing back to the Rails ecosystem in the process.

Rails roles are also becoming more specialized. Junior opportunities are scarcer; most open positions are for mid-to-senior engineers with years of experience. But those who are experienced? They’re doing just fine. Stack Overflow’s 2023 survey ranked Ruby as the 4th highest-paying tech globally. Senior Rails engineers in the U.S. regularly clear six figures.

This is where the COBOL parallel kicks in: high compensation, low visibility, and a shrinking pipeline of new devs.

Let’s kill the idea that Rails is frozen in time. It’s not.

Both Rails 7 and 8 are pushing forward with features that sidestep frontend fatigue. Hotwire, Turbo, and Stimulus let you build snappy UIs without reaching for React or Vue. Want realtime updates without drowning in JavaScript? Rails has that baked in.

On the backend, Ruby is still evolving. Turning 30 next year, it’s the same age as JavaScript, and it remains in active development. The Ruby 3×3 initiative, launched back in 2015, committed to making Ruby 3 three times faster than Ruby 2. That milestone was reached in 2020, and the momentum hasn’t stopped. Recent versions continue to bring performance gains through JIT compilers like YJIT and RJIT, as well as improvements to memory efficiency and startup times.

Rails 8 builds on this foundation. It is the version of Rails that remembers why people fell in love with it in the first place: fast setup, clear conventions, and a full-stack story that doesn’t require Kubernetes on day one. It even introduces “Solid Queue” for background jobs — no Redis, no drama.

And beyond the tooling, there’s still joy in writing Rails. As DHH recently pointed out in his post Coding should be a vibe!:

If developers are racing to offload coding to AI, maybe the problem lies in the stack itself.

Rails and Ruby offer a different path. It’s one that doesn’t require hiding the mess. Instead, they strip away unnecessary layers and let you build fast, clean, and human-readable code from day one. In that world, simplicity and elegance aren’t limitations. They’re advantages.

That’s also why we don’t skip upgrades. All of our active projects are already on Rails 7, and a couple have already adopted Rails 8. We use Hotwire and Turbo where it makes sense. Not because it’s fashionable, but because it solves real problems. Staying current gives us access to the latest features, but more importantly, it keeps our clients’ products secure.

So, is Rails becoming the boutique skillset for aging SaaS platforms?

Maybe. And that’s not a bad thing.

Rails still excels at building internal tools, MVPs, and stable CRUD-heavy platforms — especially for teams that value clarity over cleverness. Its “boring is good” philosophy is a feature, not a bug.

The community remains active, too. The main Rails repo has seen over 6,500 commits and 1,500 issues closed in the past year. RailsConf draws a mix of grizzled veterans and Hotwire-happy newbies. Tools like StimulusReflex and view components show there’s still innovation happening, just at a more grounded pace.

The language and framework remain deeply aligned around developer happiness and productivity. Drastic deviations are unlikely to succeed, because what’s here doesn’t just work, it works very well. Newer languages and frameworks have their place, but Rails wasn’t built for the same constraints or audiences.

Rails isn’t a zombie. It’s simply not chasing trends anymore. It’s found its lane, and for the right teams, it’s still a dream to work with.

Ruby on Rails isn’t dying. It’s aging into its next role. Think less rockstar, more session musician. Still sharp, still useful, still quietly keeping the show running.

It might not be the framework new grads rush to learn, and it might not top the charts anymore. But for many companies, Rails is still a pragmatic choice. It delivers. It scales (when engineered well). And in a tech world increasingly obsessed with complexity, Rails dares to stay simple.

Smart engineering teams are well-aware: smart, stable software never goes out of style. So maybe, in 10 years, we’ll talk about Rails the same way we talk about COBOL: a relic, yes — but a reliable one. And in the end, reliability is underrated.

At Infinum, we’re here for both sides of the Rails story. Both if you’re looking to extend the life of a legacy system, or weighing Rails against shinier options for a new build. Check out our Rails Maintenance & Support services if your app needs some love (or a performance tune-up), or reach out if you’re on the fence about which tech stack fits your product best.

Deciding whether to build your Ruby on Rails product in-house or find an outsourcing company? The hire vs outsource Rails companies dilemma can be tricky, so we weigh the pros and cons of both approaches to help you choose the best path for your project.

Ruby on Rails, affectionately known as Rails, has been a cornerstone of web development for nearly two decades. With its “convention over configuration” philosophy and robust ecosystem, Rails development can produce scalable and maintainable applications at speed.

Not the latest, trendiest technology, Ruby on Rails is a powerful and flexible framework backed by one of the most active and supportive developer communities. It’s no wonder that companies like Airbnb, GitHub, SoundCloud, Netflix, and Shopify grew from startups to industry leaders with Rails as the foundation of their tech stack.

Mature and stable, in 2025, Ruby on Rails will remain the technology of choice for many startups and large enterprises. However, deciding whether to build your product with an in-house team or to outsource the work to a Rails development company can be as intricate as the framework itself.

While we’ve already reviewed the matter of in-house development vs outsourcing in general, this article explores the unique considerations for Ruby on Rails development to help you make the right choice for your business.

In-house developers familiar with your business domain and Rails-specific practices can be a great asset. Over time, the team develops a deep understanding of your industry’s nuances and can tailor Ruby on Rails’ conventions to fit specialized needs. This can be particularly valuable for organizations whose entire core business revolves around a Rails-powered product, and who are prepared to invest in building and maintaining a dedicated team for the long haul.

When your Ruby on Rails developers and other key roles (designers, project managers, etc.) all work in the same physical space, the development process can benefit from more organic, day-to-day interactions. It gives you the option of impromptu discussions and quick clarifications – especially if face-to-face collaboration is the norm in your organization.

Investing in an internal team means growing their expertise in the Ruby on Rails framework (conventions, best practices, upgrades) and supporting libraries like RSpec. If you already have robust processes in place for continuous learning and knowledge-sharing, the team’s expertise can grow significantly over time.

As an internal dedicated team builds and maintains your Rails application, they develop a deep understanding of its quirks, dependencies, and overall structure. This institutional knowledge can mean faster troubleshooting and fewer knowledge-transfer hurdles down the road.

Ruby on Rails developers, especially those with deep expertise, are highly sought after and increasingly scarce. Finding and retaining such talent can be time-consuming and expensive, especially if your company doesn’t position itself as a major tech employer with compelling Rails-specific growth paths.

Beyond salaries (which are also expected to rise as developers advance), recruiting and retaining a Ruby on Rails team involves substantial costs, including the hiring process, continual training, and providing the resources for tools the team will need in their work. Over time, these costs add up and might not be justifiable unless Rails development is a central pillar of your business.

While in-house teams develop strong domain-specific knowledge, they focus on a single project and may lack experience with the broader Rails ecosystem. Outsourcing companies often have experienced developers who have worked on different project types and scales, which equips them to suggest unconventional but effective solutions that your team may not have encountered.

Ruby on Rails is mature but still evolving – new gems, patterns, and framework improvements surface regularly. Without exposure to the broader community or external experts, an in-house team risks falling behind on Rails trends, which could limit your product’s development velocity, long-term health, and ability to stay current and competitive.

An experienced Ruby on Rails agency typically works across multiple industries and project types – for example, our engineers have worked on over a hundred different development projects! This broad expertise often leads to creative, well-informed solutions – like optimizing complex queries in ActiveRecord or setting up scalable background job processing infrastructure specific to Sidekiq.

The hiring process for building a team from scratch can take months, while outsourcing provides instant access to a full-fledged team of Ruby on Rails professionals. This rapid onboarding is especially valuable if you need to go to market quickly, tackle a technically complex project, or start a long-postponed dependency upgrade process.

A development company can scale your outsourced team up or down, depending on your current project requirements. For instance, you might need additional backend developers during the early development phase and fewer resources post-launch. With outsourcing, you only pay for the capacity you require rather than sustaining a large full-time team year-round.

Specialized agencies are immersed in the Ruby on Rails ecosystem. They stay up to date on everything from performance optimizations to compatibility with the latest versions. Their exposure to a wide range of challenges – and their corresponding solutions – can support rapid Rails development and significantly enhance your project. 

External developers may not fully mirror your internal processes or business context on day one. Depending on your choice of outsourcing company, seamless integration can be challenging, but a reputable partner will prioritize understanding your workflows and domain to minimize disruptions.

If you’re outsourcing Ruby on Rails development, it can mean relinquishing some oversight on the nitty-gritty of engineering. However, transparent processes, frequent check-ins, and collaborative project management tools (like Jira or Productive) can ensure you always know what your outsourced team is working on.

Handing over an existing codebase or domain knowledge can feel challenging. Clear documentation, regular syncs, and well-defined onboarding processes go a long way here – and experienced outsourcing partners often have protocols in place for those scenarios. It also helps when an agency knows what to ask.

Code quality can vary among outsourced teams. When outsourcing Ruby on Rails development, it’s crucial to choose a partner that adheres to Rails best practices, invests in thorough code reviews, and enforces consistent standards – so that your product remains maintainable and future-proof.

If you decide to outsource your Ruby on Rails development project, here are a few tips from an experienced partner agency to make sure you reap all the benefits – and none of the pitfalls:

If you’re outsourcing Ruby on Rails development, this checklist can help sidestep the usual concerns. By choosing the right agency partner, you can tap into the full potential of a specialized Rails team – no compromises necessary.

Ruby on Rails is a powerful tool for building modern web applications, and it comes with its own set of nuances – everything from major version upgrades to discovering the perfect gem for a particular task. 

The decision whether to hire vs outsource Rails companies ultimately hinges on your immediate project needs, long-term goals, and the unique challenges of the ecosystem. As you weigh in-house vs outsourced software development, consider the extent to which you can sustain the costs, recruitment efforts, and ongoing learning a Ruby on Rails team requires.

However, this choice doesn’t have to be an either/or scenario. However, this choice doesn’t have to be an either/or scenario. You can also tap into development services through hybrid models like team augmentation, combining the strengths of both approaches. For instance, an in-house team can define the core vision and maintain the product post-launch, while an outsourced partner provides expertise during development and scales resources as needed. 

With the right balance, you can leverage Ruby on Rails’ full potential to build a product that aligns with your business goals and evolves with your users’ needs. If you need any help with development services, check out what our Rails team can do for you. 

Open-source dependencies are practical, convenient, time-saving – and sure to make your life miserable if left unattended. Read on to learn how we optimized our dependency maintenance process and got all our Ruby on Rails projects updated to the latest versions with minimum time loss.

Modern applications and frameworks are composed of hundreds of individual dependencies.  Using third-party libraries, frameworks, and other ready-made software components is a time-saver during development. However, dependencies can also incur an often overlooked maintenance cost.

As a digital agency, we often find ourselves in a situation where we need to perform maintenance on applications with severely outdated dependencies that haven’t been updated in years. These apps present a series of challenges – upgrade efforts are estimated in months, the development pace is slower, and they are often susceptible to numerous security vulnerabilities.

In this article we will present our process and tooling improvements that helped us increase dependency health for more than 20 Ruby on Rails projects under our maintenance in the last couple of years.

Modern software development relies heavily on open-source dependencies. The developer community maintains countless dependencies for all possible use cases in the diverse software landscape. Feature development used to take a lot of effort, and now a large portion of it can be easily replaced by adding a single line to the Gemfile and setting some initializer options. It’s an elegant solution – why write lines and lines of code when the dependency’s author already designed, implemented, reviewed, and tested the exact functionality your project requires; all you have to do is include it.

This is not reserved only for the Ruby ecosystem; other software development camps also heavily rely on the work of open-source authors.

However, the problem with using third-party components is that we tend to take care of our own code garden and rarely think about maintaining downstream dependencies. Our codebases evolve, but so do our dependencies. 

Open-source authors spend considerable time maintaining their libraries during their support life cycle. They introduce new features, fix bugs, and even introduce performance enhancements. All we have to do to reap the benefits is to upgrade to the current version, yet we seldom do so.

One of the benefits of agency work is the variety of projects and situations that we encounter. During the last 18 years, we’ve worked with countless client applications, and at any given moment, we’re also actively maintaining around ten internal ones.

It’s not uncommon for us to take over a larger client project that is two or more Ruby on Rails versions behind. Just recently, we started supporting a Ruby on Rails project started seven years ago, and dependency upgrades were the first order of business. Bringing the application to the latest major Ruby and Rails version took more than 500 hours of development work. That’s a big chunk of time to pay for a one-time upgrade. 

However, this situation is far from uncommon – even GitHub took a year and a half to upgrade Rails from 3.2 to 5.2 before they adopted a continual upgrade strategy.

Understanding framework changes, auxiliary gem changes, and how they interact with your codebase is a big undertaking. Running bundle update devise for a single dependency is trivial, but understanding the change described in a dependency changelog requires a lot of context. Good automated test coverage helps build confidence in the upgrade, but we’re still often pushing out a risky code change we aren’t entirely comfortable with.

Always focusing on client-requested feature work, we were also guilty of often sweeping our dependency updates under the carpet. When Rails 7 was introduced around two years ago, we were faced with the exact amount of our technical debt.

Wanting to capitalize on all the newly related features (ActiveRecord encryption, ActiveRecord load_async) across all projects under our care, we decided to conduct a fleet dependency health review.

Most applications shared some common characteristics:

Bringing just one project up to date seemed like a big chore and getting all of them back on track seemed infeasible. We have performed considerable dependency upgrades before, but planning, estimating, and safely executing a mass wave of upgrades on applications under our care was uncharted territory.

We realized that we couldn’t continue on the same upgrade path. Our team needed to improve our dependency upgrade culture and processes to repay the debt and prevent it from accruing again. It was time to figure out how to perform the upgrades safely and do a better job of tracking and executing dependency upgrades on internal and client projects in the future.

After interviewing several internal project teams and looking at industry best practices, we identified the weakest points in our dependency upgrade culture and came up with a set of resources and guidelines to help us get to the next level.

The most significant change we introduced was mandating small but frequent dependency upgrades on all projects. Regular (and minor) dependency upgrades are more predictable, safer, and easier to plan than large ones. With a little inventiveness, all upgrades can be performed in bite-size chunks.

Upgrading dependencies is a never-ending process since new versions are released daily. To stay on top, we need to be as efficient as possible. Not all dependency upgrades have the same impact, and we should prioritize them accordingly:

We emphasized the urgency of the security upgrade by requiring all project teams to perform CVE triage and resolution within one business day. Each additional day of exposure to a CVE in the wild increases the likelihood that an automated vulnerability scanner will find the application and exploit it. 

Rails upgrades should be carefully researched and planned in multiple stages as defined by our guide. Revolutionary upgrades are strongly discouraged. We want to move in small, predictable, and reversible steps to reduce the likelihood of regressions. 

Project dependency health should be easy to determine programmatically. Tracking it for all projects under our care over time allows us to gauge our progress and hold data-backed discussions with stakeholders.

Implementing these changes required not only changing the process but also some new tooling.

Tracking dependency health over time can be performed manually for individual projects, but keeping up with the 20+ active projects we support requires some automation. We decided to invest some time into building basic and effective tooling that would enable us to easily keep an eye on the health of our applications.

For this purpose, we built an application called Revisor. It periodically aggregates Ruby dependency health data of all the projects in a GitHub organization and exposes it in a simple dashboard.