A few weeks ago, I had the chance to step in and rescue a Ruby on Rails project.
At first glance, everything was looking nice. The application was running smoothly, and also more than 200 paid users were using it. New features were being added regularly based on user requests, and the product also appeared to be moving quickly and delivering value.
However, once I started exploring the codebase, a different picture began to emerge.
Much of the code had been written to what many developers refer to as “vibe coding”. Decisions had been made quickly, features were built on the fly, and structure often took a back seat to speed. There were few tests done, but the business logic was scattered across controllers, models, and helpers.
The application worked technically, but when I spoke with the development team, it became clear that no one felt entirely confident while making changes to the code.
If you have worked on projects like this before, you might probably recognize the situation. The product is active, but the codebase feels fragile and difficult to maintain.
The Good News: Rails Is Built for This
One of the things that makes Ruby on Rails such a powerful framework is its strong set of conventions.
Rails projects drift away from those conventions when teams are moving quickly. The advantage of a framework with clear opinions is that it gives developers a path to bring things back in order.
The focus can be on gradually restoring structure instead of rewriting the entire application.
Step 1: Bring Back the Conventions
The first step was not rewriting the features. It was simply bringing the project back in line with Rails conventions.
This included things like:
- Keeping controllers lightweight and focused on request handling.
- Moving business logic into models or service objects
- Removing duplicated logic
- Following clear naming patterns
- Organizing the project structure properly
Rails’ “convention over configuration” philosophy makes this process surprisingly effective. The codebase becomes easier to understand and far more predictable, once the project aligns with those conventions again.
Predictability is essential for teams working collaboratively.
Step 2: Add Tests Where They Matter
The next step was introducing the tests.
The focus was placed on the most crucial parts of the system rather than attempting to cover everything immediately. This included key user flows, core business logic, and important API userpoints.
Rails provide solid testing support out of the box, whether you use Minitest or tools like RSpec. The small number of well targeted tests significantly improved the confidence while modifying the code.
Developers could make changes with much less risks, once these tests were done.
Step 3: Clean Up the Deployment Lifecycle
Another area that needed much attention was the deployment workflow.
The deployments often become informal in the fast moving projects. A few manual commands are run on a server. If something breaks, a quick fix is applied, and the process repeats.
However, Rails applications benefit greatly from a structured deployment process.
A reliable Rails deployment setup typically includes:
- Version-controlled codebase
- Automated tests before release
- CI checks on every push
- Clear environment configurations
- Predictable build and deploy steps
- Rollback capability if something fails
The deployments became much more predictable and far less stressful, once these practices were introduced.
Step 4: Letting Rails Do What Rails Does Best
Another common issue in many projects is trying to work around the framework instead of using it effectively.
Rails already provides well-established solutions for many common problems, like authentication, background processing, data validation, and API deployment.
The development becomes much more efficient and the overall system becomes easier to maintain by leaning into the patterns and tools Rails already offers.
The Result
After roughly two weeks, several gradual improvements were made:
- The codebase became significantly easier to navigate
- New features could be added more confidently
- Developers felt more comfortable working within the system
- Deployments became predictable and reliable
Most importantly, the application did not need to be rewritten. The improvements came from restoring the structure and following Ruby on Rails best practices.
Final Thoughts
Vibe coding is not a bad approach at all. In early product stages, it can help teams move quickly and validate ideas.
The structure becomes increasingly important, as an application grows and more developers become involved.
This is where Ruby on Rails continues to stand out.
Rails allows teams to move quickly in the beginning, while providing the conventions and tools needed to bring order to a growing codebase.
In many cases, teams also benefit from a dedicated Ruby on Rails maintenance service to keep the application stable, optimized, and easy to scale over time.
This balance is why still today, Rails remains a strong choice for building real and maintainable applications.
