You've inherited a Rails app. Maybe an agency took on the client. Maybe a new CTO walked into a codebase the founding team built and left. Maybe an acquisition came with a system nobody quite remembers building. Either way, the code runs, but every change feels expensive, and the team is more cautious than they should have to be.
That's the moment I'm hired for. Not "more Rails capacity," but a principal-level engineer who's done this enough times to know what to look at first, what to leave alone, and what to fix before it bites.
What I do first
An honest, written diagnosis. Where the structural drift actually lives. Which parts of the codebase are scary because they're complex and which are scary because they're undocumented (those are different problems with different fixes). What "small changes" are actually safe today, what isn't, and which three or four boring fixes would buy back the team's confidence fastest.
I'd rather spend a week reading and writing than a quarter discovering. The output is usually a short, opinionated document, the kind I'd want to hand to a board or a client to explain why the next quarter looks the way it does.
How I work with your team
Alongside, not above. I pair on the hard parts, leave a paper trail of every meaningful decision, and make sure the people staying behind understand the changes deeply enough to extend them. The goal is never "Simon is the only one who understands this part." That's the failure mode of a lot of inherited-codebase work, and I actively design against it.
If you're an agency, I'm the senior Rails head you can put in front of the client. If you're an internal team, I'm the principal partner who can have the awkward conversations the codebase forces.
What you walk away with
A codebase your team can change without flinching. The structural decisions written down so the next engineer doesn't have to rediscover them. A clear picture of what's "good enough for now" and what genuinely needs investment over the next year, separated honestly, not bundled into one scary backlog.
In for the long term
Most inherited-codebase engagements turn into long-running ones, because the same instincts that helped you recover the codebase tend to help with what comes next. Most of my clients have worked with me for years, not weeks. If we work together once and it goes well, I'll still be around when you need me next.
