People focus so much on <h1> and alt attributes that they forget about usability.

Introduction

When discussing accessibility (a11y), we all focus on the structure of our <h1>/<h2>, the alt image texts, the contrast, and all the necessary rules to be covered. The problem is that during the process, we forget to think about usability: Is the page saying what it is supposed to be saying? Does the image description reflect what you can see there? Or take link text as an example: Does “Read More” explain what content the user is about to access?

Most of the time, usability is overshadowed by a focus on compliance with accessibility standards. As a result, we end up with a site that passes validation but neglects to measure usability… or worse, we don’t even consider it.

Last weekend I migrated my Doctor’s App from Heroku to Railway.

It’s a multi-tenant Rails app where each hospital gets its own subdomain, one.doctors.com, two.doctors.com, and so on.

Five hospitals, around 25,000 appointments, 9,700+ patients. Not huge, but not trivial either.

Here’s how it went, including the part where I accidentally broke the database.

For more than 8 years, we have been publishing detailed guides on how to upgrade Rails applications.

We have documented every minor version from Rails 2.3 through 8.1 in our Rails Upgrade Series and distilled our methodology into an ebook: The Complete Guide to Upgrade Rails

All of that knowledge comes from more than 60,000 developer-hours of hands-on upgrade work for companies of all sizes, from solo-founded SaaS products to huge Rails monoliths running at Fortune 500 public companies.

Today, we are making that methodology available to everyone as an open source Claude Code Skill: claude-code_rails-upgrade-skill.

For the past twenty years, TitleLeaf has been helping educational book publishers maintain and share their content with industry partners such as reviewers, wholesalers, and distributors. Its robust content management system and handcrafted digital solutions simplify the process of sharing metadata, digital assets, and marketing material for the book industry.

Here was the situation

Tim Peterson, Founder of TitleLeaf, is a solopreneur balancing the challenges of entrepreneurship with a flexible lifestyle. One of his dreams is to have more time and freedom to do what he enjoys most—skiing and biking in the mountains of Northern California while still running his company as efficiently as possible.

Peterson’s goal is to build an ever-evolving, feature-rich SaaS service and share his domain knowledge with customers without having to manage a team or chase technical updates:

“I got fed up chasing contractors and micromanaging. I tried hiring and outsourcing, but nothing was the right fit. I just wanted reliable maintenance so I didn’t have to worry about it.”

This article is part of our Upgrade Rails series. To see more of them, click here.

This article will cover the most important aspects that you need to know to get your Ruby on Rails application from version 8.0 to version 8.1.

Last month, we finished a big upgrade for a client. The client had 2 main pain points for their app. The first one was that they were using Rails 2.3 LTS with Ruby 2.5. The next big issue was that the test suite took 40 minutes to run, blocking engineers from merging code into the main branch, and also slowing down the whole feedback loop for every code change.

After finishing the upgrade (we got the application to Rails 8.1.1 and Ruby 3.4.7), we focused our attention on improving the test’s speed and we reduced the time it took to run the whole test suite (over 10k tests) from 40 minutes to around 4!

Today is a sad day because last week a platform that we know, like, and trust made a surprising and disappointing announcement.

On February 6, 2026, Heroku published an update on the future of the platform. The announcement confirms what many in the community had suspected for a while: Heroku is transitioning to a “sustaining engineering model.”

In plain English, that means maintenance model: No new features, no new Enterprise Account contracts for new customers, and a focus on stability only.

If your Rails application runs on Heroku, this is the moment to start thinking about your next move. The platform is not disappearing overnight, but the direction is clear: Heroku’s best days are behind it and it’s time to migrate on your own terms to a provider that is not on maintenance mode.

Considering all this we are announcing a new productized service by FastRuby.io: Our Heroku Migration Service.

A few months ago, we were working on a Rails 7 app using Webpack 5. One of the main problems we had was that making a small change in the Javascript took around 39 seconds to recompile. You can imagine how much productivity we lost just waiting, and honestly, I personally remember getting really distracted during that dead time, just sitting there.

At that point, Webpacker had been retired, so we checked the official migration guide and found several options: the first was jsbundling-rails, the second was Shakapacker, another was Importmaps, and finally, we knew we had the option to try Vite.

We finally went with Vite, which (as noted on GitHub) is named after the French word for “quick” (pronounced /vit/, like “veet”). Our reload time improved a lot, it dropped to just one second, which felt like magic. In this post, I’ll explain why we chose it, and also why we got such a huge speed improvement.

After we’ve addressed all the deprecation warnings and successfully dual-booted an application, the next step in a Rails upgrade is often the most challenging: fixing the broken build.

At this point, the test suite is red, and our job is to bring it back to green. This phase can feel chaotic, but over the years at FastRuby.io, we’ve developed a process that makes it systematic and (relatively) predictable.

In this post, I’ll break down how we approach this step, what patterns we’ve noticed, and how we debug the trickiest failures.

At OmbuLabs, open source has always been at the core of our values. This year, for Hacktoberfest 2025, our team took the opportunity to give back to the communities that power our daily work, from Ruby developers tackling technical debt to those building the next generation of AI tools. Throughout October, we dedicated focused internal time to open source contributions. Our goal was twofold:

1. Strengthen and maintain the tools that power our work at FastRuby.io, helping teams manage technical debt and improve code quality.
2. Advance Ruby’s presence in artificial intelligence, contributing to libraries and frameworks that integrate Ruby with modern AI technologies. By aligning Hacktoberfest participation with our mission to give back, we turned this month into an opportunity for growth, learning, and meaningful community impact.

The beauty of Ruby’s open source ecosystem lies in its simplicity: add a gem, and you instantly gain powerful new features. But this same convenience can also expose your application to hidden threats. In recent years, attackers have increasingly targeted the supply chain, where dependencies, not code you write, become the weakest link. This post explores how supply chain attacks happen in RubyGems, gives real-world examples, and practical ways to protect your Rails projects.

A typical scenario in the Rails world, after spending some time using it and playing with forms and requests, you realize that not everything is magic, there is some code that is in charge of cleaning things up so that you get in your controller the params, headers, and other request data that you need.

That’s where Rack comes in. Rack is the code that lives between the layers, from the moment the request starts until it reaches your controller. But it’s not just about input, the output works the same way. When you return something from your controller, Rack is there too.

In this post, we’ll cover a few examples where understanding how middleware works can help you solve real-life problems.

Rails 8.1 is set to bring a new API, Rails.event.notify(...), that will help make it simple to publish structured events that are immediately consumable by monitoring and Application Performance Monitoring (APM) platforms like Datadog, AppSignal, New Relic, or Honeycomb.

In this post, we’ll look at how it works, why it matters, and how to prepare your app for data-hungry observability tools.

DHH unveiled Rails 8.1 during his keynote at Rails World 2025, releasing the first beta live on stage. This new version brings a suite of tools aimed at making Rails apps simpler to build, maintain, and collaborate on. With a strong focus on developer experience and consistent workflows, Rails 8.1 helps teams sidestep common frustrations and work together more smoothly.

Maintaining a Ruby on Rails application often slips down the priority list. Everything seems fine, until suddenly it isn’t. A gem update breaks a feature, a security flaw makes headlines, or your app refuses to deploy after a server upgrade. When that happens, teams scramble to find help, often at the worst possible time. This “as-needed” upgrading approach may appear cost-effective in the short term, but it leads to stress, downtime, and unpredictable expenses.

But there is a smarter path forward: fixed-cost monthly maintenance. In this post, you’ll see why investing in a maintenance retainer is better than reactive upgrades, and how our service delivers value month after month.