This page covers the specific work I take on, what's included in each engagement, and how projects typically start. If you've already read the homepage, this is the operational detail.
Four engagement types. Most projects map cleanly to one of these — and many start as a short audit before turning into focused work or ongoing support.
Help with Rails 6.x and 7.x upgrade planning and execution — including upgrades that have stalled on a long-running branch, feel risky to ship, or need a clear path through framework defaults and gem changes.
new_framework_defaults review and incremental enablementload_defaults, Zeitwerk, autoloadingA staged upgrade plan where each step is independently shippable, and the upgrade actually executed against your production environment — not a long-running branch that never merges.
Stabilizing Rails apps that are running in production but have become hard to maintain — fragile workflows, recurring incidents, legacy patterns, and bugs that are hard to reproduce locally.
Specific production issues resolved, the riskiest workflows documented with tests around them, and a short list of follow-up fixes the team can keep working on without me.
Investigating and fixing performance, caching, and background-job issues in production — slow endpoints, ballooning Redis memory, stuck queues, duplicate jobs, and the kind of issue where the symptom is obvious but the root cause is not.
Worst offenders addressed with measurable improvement, background-job reliability restored, and instrumentation in place so the next regression is caught early — not in production.
Senior Rails capacity, month to month, for teams that don't need a full-time backend hire but do need someone reliable to lean on — founders, CTOs, and agencies who want continuity without the overhead.
A reliable senior pair of hands, predictable monthly capacity, and steady progress on the backend work that usually slips when the team is busy shipping features.
Most projects start with a short technical review. I look at the Rails and Ruby version, gems, deployment flow, background jobs, caching, logs, and the main production risk. After that, I suggest one of three paths: a focused fix, a written upgrade or debugging plan, or ongoing support — depending on what the app actually needs.
Three ways to work together. Pick the one that fits, or start with an audit and decide from there.
A focused review of your Rails app — versions, gems, deployment, background jobs, caching, and production risk. Delivered as a written report with prioritized findings and recommended next steps. Useful before an upgrade, after a handover, or when you want a clear-eyed second opinion.
A defined piece of work with a clear scope — a Rails upgrade to a target version, a specific performance issue resolved, or a reliability problem investigated and fixed. Defined timeline, written outcome, fixed price or capped budget.
Ongoing senior Rails support, billed monthly. A predictable number of hours per week for code review, bug fixes, upgrades, debugging, and steady backlog progress. Useful when you need continuity without hiring full-time.
Send me a short description of your Rails issue. I'll reply with possible next steps.
Book a Rails consultation