Do you work as part of the team or on your own?

Whichever suits you. Most clients want me in the team's normal flow: same repo, same reviews, same chat. Some prefer I take a whole piece and deliver it end to end. Both work, and I'll write updates either way.

How many hours a week can you give us?

That's agreed up front and written down. I keep a small number of clients at a time, so you get real attention rather than leftover hours.

Can you work in our time zone?

I work remotely, on Pacific time, and keep a few hours of overlap with your team for questions and reviews. Most of the work runs through pull requests and written notes, which don't depend on time zones.

What if we only need help for a month?

That's fine. A single scoped piece is a perfectly good engagement. The documentation means stopping is easy, and starting again later is just as easy.

Do you use AI coding tools?

Yes, the way any senior engineer does now: as a tool I direct and check, inside your rules. If your team has policies on AI tools or code access, I follow them.

What happens when the contract ends?

Your team has everything: the code, the tests, the docs, the runbooks and the agent instructions. Nothing depends on me. If you want me back for the next piece, the same documents get me up to speed in a day.

Your Rails Team Is Stretched. Here Is How a Senior Contractor Fits In Without Slowing You Down

More work than senior hands

Your team is good. They know the product and the customers, and they ship. But the roadmap has grown faster than headcount, or your most senior developer left and took a lot of context with them. Now the hard tickets wait. The integration a big customer asked for has been “next sprint” for three sprints. The tricky data migration keeps getting pushed because nobody has a clear week to do it.

Hiring a permanent senior takes months, and you’re not sure yet whether you need one full time. What you need now is someone who can take a defined piece of work, get it done well, and not need hand-holding to do it.

That’s the gap I fill. Your team keeps the direction and the product knowledge. I add senior capacity and the technical foundation underneath the work I take on.

What I take on

Scoped pieces, each with a clear outcome, so you always know what I’m working on and when it will land:

Features, from the data model to the screens, with tests.
Admin and internal screens that your support or operations team has been asking for.
Integrations with payment providers, CRMs, accounting systems, webhooks and partner APIs, built to handle retries and failures properly.
Tricky migrations: moving data between models, splitting a big table, changing a column on millions of rows without downtime.
Background jobs and performance work when a page or a process has outgrown its first version.
Upgrades and cleanup that the team never has time for.

I work the way your team works. Your repo and branching model. Your pull request and review process, and I’m happy to review your team’s code too. Your standups and planning meetings if you want me there, or written updates if you’d rather not add another face to the call.

Figure 1. How I fit in. Your team sets direction; I take scoped work through your normal process and hand it back documented.

I don’t disappear

The most common complaint about contractors is silence: two weeks of nothing, then a giant pull request nobody can review. I work the other way. You get a short written update every few days: what’s done, what’s next, what’s blocking me, and any decision I need from you. Pull requests stay small enough to review in one sitting. If something turns out bigger than we scoped, you hear about it as soon as I know, not at the deadline.

Documentation, so your team owns the work

Everything I build is written up so it belongs to your team, not to me:

An overview of each piece of work: what it does, how it fits the rest of the app, where the data lives.
Runbooks for anything that needs operating: rerunning a failed sync, rotating a partner API key, backfilling data.
Decision notes on why it’s built the way it is and what was considered.
Performance numbers where speed matters, measured before and after.
Instructions for AI assistants, added to your repo’s agent files, so the next person working in that code with an AI tool gets accurate help.

You own the code, the docs and every account involved. When the contract ends, nothing leaves with me.

Why me

I spent seven years as a senior engineer on a multi-tenant B2B SaaS that grew from about $4M to $13M in annual revenue. I worked across the whole Rails app, ran its roughly 1TB Postgres database, and cut the company’s AWS bill by six figures a year. I now build and run a live Rails 8 product on my own, and I have a merged contribution to the faraday Ruby HTTP library. I write about the engineering on my writing page, including zero-downtime migrations, audit logs and N+1 queries at scale.

Take a business like this one

The business in this section is a composite of the kind of company I talk to, not a named client. The numbers are the shape of the problem, not a case study.

Picture a healthcare staffing company with a Rails app and a team of four developers. Their senior engineer left two months ago. The team is capable but newer to Rails, and three things are stuck: an integration with a large client’s HR system, a migration to split one overloaded table of shifts into two, and an admin screen the operations team has wanted for a year.

What I’d do for a business shaped like this:

First week: get oriented. Set up locally, read the parts of the code each piece touches, and write a short plan for all three, with a rough order and size for each.
The integration first, because a client is waiting. Built with retries, logging and a runbook for when the client’s system is down.
The admin screen next, paired with one of the team’s developers so they can extend it later.
The table migration last, done in stages with no downtime, each stage tested and deployed on its own.
Written updates every few days throughout, and small pull requests the team reviews.
Documentation for each piece in the repo, plus updated AI-assistant instructions, so the team owns all three once I step back.

The team keeps doing what they know best: the staffing business and the people who use the app every day.

What it costs

It starts with a small first piece at a fixed price: usually one well-defined ticket or a short written plan for a larger piece. You see how I work, in your code, before committing to more. After that, work is scoped and quoted piece by piece, or as a set number of hours a week for a period. No long lock-in, and no agency markup.

What I need from you

Access to the repo, the issue tracker and your team chat. A staging environment. One person who sets priorities and answers product questions. Someone to review my pull requests, the same way you’d review a teammate’s. And your honest view on how the team likes to work, so I fit in rather than the other way round.

Your Rails team needs another senior. I'll work like one of yours.