When people hear the phrase “technical debt”, they often picture broken code, outdated infrastructure, or a total rewrite waiting to happen. But in our experience at Planet Argon, technical debt usually shows up more quietly.

It’s not a crisis. It’s a pattern.

It shows up in how long it takes to make changes, how often bugs sneak in, and how hesitant developers are to touch certain parts of the codebase. And while it rarely announces itself, it always costs something — whether in time, budget, or momentum.

In this post, we’ll highlight real-world examples of how technical debt has surfaced in Rails applications we’ve worked on. These aren’t horror stories — they’re common issues we see even in well-run projects. More importantly, we’ll share some ways teams can manage debt strategically without a massive rewrite.

At FastRuby.io, we deeply value the Ruby and Rails communities and believe in giving back through open source contributions. We wouldn’t be where we are today if it wasn’t thanks to a lot of open source projects we use on a daily basis.

We actively use, maintain, and enhance several tools designed to empower developers and teams who want to handle Ruby and Rails upgrades themselves, especially those who might not have the budget to hire our services.

These open source projects facilitate upgrades by improving transparency, managing technical debt, and ensuring smooth transitions between Ruby and Rails versions.

Here’s an overview of each tool and how it can support your next upgrade project.

Whether you’re debugging a dependency issue, checking for an optional gem, or just curious about what’s loaded in your Ruby app, there’s a handy command that can help:

puts Gem.loaded_specs.keys.grep(/your_pattern_here/)

In this article, we will discuss what this command does, what exactly it’s checking for, and its limitations.

At FastRuby.io, we offer specialized Rails upgrade, maintenance, and technical debt services.

Before doing an upgrade, we strongly recommend doing the Roadmap to Upgrade Rails, a static analysis of your codebase that outlines the action plan to do the upgrade and provides time and investment estimates.

The first step in every Rails upgrade we do is addressing deprecation warnings in the current version. So recently, we set out to extract all deprecation warnings from all versions of Rails starting at Rails 2.3 to help in our static analysis of Rails applications.

Having reproducible development environments is one of the best ways to guarantee ease of application setup and code sharing in teams. Dev containers are a way to achieve this.

In this article we’ll try to give you a small introduction to what dev containers are at their core and provide a minimal example on how to set up a Rails application to use dev containers.

In this article we will present compatibility between Ruby and Heroku across different versions. In the process of upgrading really old applications to more modern versions of Ruby we have run into a lot of these combinations.

In Ruby, we often want to rename methods or attributes for clarity, to extend functionality and for compatibility. However, there are three different tools for this, each with its own use case and behavior: alias, alias_method and alias_attribute.

In this post we’ll go over each one of them, what they actually do and when to use them.

Founded in 2011, Valid Eval provides a secure, SaaS-based platform that helps organizations make defensible, data-driven decisions in high-stakes situations involving many applicants, subjects, domain experts, and judges. The Denver, Colorado-based company primarily serves federal government agencies that need to evaluate complex bids before awarding contracts.

Aysan recently wrote about accessibility testing in Rails applications using your test suite to ensure that your application is accessible to all users.

However, you may not have a test suite in place or you may not have a Rails application, but you still want to test the accessibility of your web application, right? So, we discovered the WAVE Web Accessibility Evaluation Tools that can help you test the accessibility of your web application, regardless of the technology stack you are using.

Does this sound interesting to you? Let’s dive in!

Have you ever found yourself wondering how to best manage your database migrations in Rails? Migrations are a powerful tool for evolving your database schema, but without proper practices, they can become difficult to manage and even lead to inconsistencies between environments. In this post, we’ll cover essential strategies for keeping your migrations organized, efficient, and in sync across development, staging, and production, helping you avoid common pitfalls and maintain a clean, up-to-date database.

In earlier versions of Elasticsearch, types were a convenient way to categorically organize documents within a single index. However, types were eventually deprecated, pushing developers toward a type-less structure in Elasticsearch 7 and later versions. Recently while working on a project to migrate a Rails application from Elasticsearch 2 to OpenSearch 2, we faced the challenge of identifying a way to replicate this behavior in a way that is allowed with OpenSearch. In this blog we will discuss how types were used for document organization and how to achieve the same behavior in OpenSearch.

For developers, segmentation faults can feel like a sudden nightmare—cryptic errors that crash your application out of nowhere. This frustration is amplified when they show up in high-level languages like Ruby, where memory management is typically handled behind the scenes. Recently, while running my Ruby application, I experienced a segmentation fault caused by a gem. The crash not only halted my program but also left me facing a daunting debugging challenge. In this post, I’ll talk about how I identified the issue, debugged it, and eventually found a solution.

Many times, when looking at applications we have written or that we see around in repositories throughout the internet, we get this feeling that whatever we’re reading has a certain complexity too it. Sometimes this complexity is manegeable and expected. Sometime it’s not. Actually, very frequently, code can be difficult to understand and we usually describe such code as being overcomplicated, for example.

But it’s not just our understanding of written code that suffers. As expected, if code is more complex, it will also require more effort on the part of the computer to execute. And while efficient code might not necessarily be easy to understand, there is indeed such a possibility as code that is hard for humans to read and hard for hardware to compute.

However, in order to try to make things simpler and, especially, in order to coordinate within teams what is acceptable and what isn’t in terms of complexity, we need something that can help us measure complexity.

There are, of course, many metrics that can be used. In this article we’ll talk about cyclomatic complexity.

There’s abundant online guidance about refactoring controllers and keeping them lightweight, but resources on model refactoring are less common. In this blog, we’ll explore some techniques for effectively refactoring models.

In this post, we share our approach to refactoring Rails applications, focusing on improving code maintainability, reducing technical debt, and ensuring scalability. Discover the tools, techniques, and strategies we use to transform complex codebases into cleaner, more efficient systems.