I get a few different kinds of calls about Rails consulting. Sometimes it’s a business that has a Rails app that’s gotten slow and nobody knows why. Sometimes it’s a startup that has an MVP and needs someone to help them scale it. Sometimes it’s a CTO who inherited a codebase and needs a frank assessment before committing to it.
They’re different situations, but they have something in common: the person calling needs an honest answer, not a sales pitch. Here’s how I think about Rails consulting and what good work actually looks like.
What Rails Consulting Is Not
Let’s start here because there’s a lot of confusion about what a consultant does versus what an employee does.
A consultant isn’t a permanent member of your team. They’re not someone you hire to just write tickets indefinitely. A good engagement has a clear scope, a deliverable (even if the deliverable is “improved team performance”), and an exit plan.
If you need another developer on your team long-term, that’s a staff augmentation situation or a hire. I do project work and retainer partnerships, but I’m not trying to become your permanent Rails employee — I’m trying to solve your problem and leave you better off than when I arrived.
The Codebase Audit
The most common starting point is an audit. You have a Rails app that’s been running for a few years. Maybe the original developer is gone. Maybe it’s gotten slow. Maybe you’ve added features that feel fragile. You want to know what you’re dealing with before you invest more.
A solid Rails audit covers:
Performance. I look at query patterns, N+1s, missing indexes, caching strategy (or lack thereof), and response times on key endpoints. Slow Rails apps are almost always slow for predictable, fixable reasons.
Security. Outdated gems with known vulnerabilities. SQL injection risks. Authentication and authorization logic. Secrets management. Most inherited codebases have at least one or two issues here.
Architecture. Is the business logic in the right places? Fat controllers? Models with 1000-line files and callbacks that nobody fully understands? These create maintenance problems and make new features expensive to build.
Test coverage. Can you change anything with confidence? A codebase with no tests is a codebase where every change is a risk.
Dependency health. How far behind is the Rails version? Are there gems that haven’t been updated in years? What’s the upgrade path look like?
The output is a written report with findings prioritized by impact. Not a list of everything that could theoretically be improved — a practical set of actions ordered by the value they’d deliver.
Team Coaching
Sometimes the problem isn’t the code — it’s that the team doesn’t have a strong enough Rails background to make good architectural decisions. Junior developers who learned Rails from tutorials often have the mechanics right but lack the judgment that comes from production experience.
In this mode, I work alongside the team. I review pull requests with real feedback, not just approvals. I pair on hard problems. I run sessions on specific topics — Rails performance optimization, effective use of Active Job, test-driven development with RSpec.
The goal is to leave the team better. Not to create dependency on me.
Architecture Consulting
The harder engagements are the architectural ones. You have a working application and you need to make some significant decisions about where it goes next.
Common scenarios:
- The monolith has gotten unwieldy and you’re thinking about extracting services. (Usually the answer is “don’t” — but let’s look at the actual data.)
- You’re adding a mobile app and need to decide whether to build a proper API layer or modify the existing app.
- Your background job system is getting complex and you need to think about how to manage it as it scales.
- You have multiple Rails apps and you’re wondering whether to consolidate or continue splitting.
These decisions matter. They set the direction for years of future work. I’ve seen companies spend a year and hundreds of thousands of dollars on migrations that didn’t need to happen because they made the wrong call at a critical juncture.
Good architectural consulting means slowing down, understanding the constraints, and recommending the boring solution that actually solves the problem — not the exciting one that creates a new set of problems.
Rescue Projects
Sometimes things have gone badly. The app is broken, the original developers are gone, and the business needs it working. I’ve rescued a few of these over the years.
Rescue work is intensive. It requires digging through code that wasn’t written with maintainability in mind, understanding domain logic that was never documented, and making changes carefully enough that you don’t break the things that are working.
I’m honest about what rescue work costs — it’s not cheap, and it shouldn’t be. Poorly written code is expensive to fix, and that’s a fact of the business. What I can tell you is that a clean rescue puts you in a position to move forward confidently, rather than staying stuck with something you’re afraid to touch.
How Engagements Work
My Rails consulting engagements typically run one of two ways:
Project-based. We define a clear scope, I deliver the work, and we’re done. Common for audits, specific feature builds, or targeted performance work.
Retainer. For ongoing support — code review, periodic check-ins, being available to answer hard questions — I work on a monthly retainer. This is often the right model for teams that need a senior Rails voice available but not full-time.
Either way, we start with a conversation about what you’re actually trying to solve. Not a pitch. A conversation.
If your Rails application has problems you’re not sure how to fix, or you need a second set of eyes on a major decision, reach out. I’m in Bardstown, KY and work with clients nationwide.