Rails maintenance & AI integration support
Ruby on Rails maintenance and AI integration support from a senior Rails engineer. You work with me directly.
You have customers to look after. I take on the bugs that keep coming back, the overdue updates and the integrations that keep breaking, so they stop eating into your week.
Most people start with a short assessment. If there's something worth fixing, I fix it. If you then want someone looking after the app every month, there's a plan for that. Email me about your app and we'll work out the right starting point.
Who you'd work with
I'm Andy Wang. I've built with Rails since 2008 and worked remotely with US and European teams since 2011. Most of my work today is Rails product engineering, plus AI features, background jobs and third-party integrations.
I also contribute fixes upstream to RubyLLM and ActiveAgent, the libraries many Rails apps use for AI features. When an AI integration misbehaves, I can usually read the library code as well as yours.
There's no account manager in the middle. The person who looks into the problem is the one who writes the fix and explains it to you.
When I can help
Errors that keep coming back, flaky background jobs and overdue upgrades all end up on the founder's desk.
You need someone who can learn the codebase and make careful changes you can review.
Payments, webhooks, email or an outside API don't behave the way they used to.
A provider changed something, the output is inconsistent, requests time out, or the bill is higher than you expected.
It works best for a Rails app that already has real users or runs part of your business. You might have a small team, or you might be the only one looking after it. If you built your app with AI tools and want something lighter, have a look at VibeCare.
What I work on
You don't need AI features to use this service. New AI features, a switch to another provider or a bigger redesign are planned as separate projects.
How to start
One-time · up to four hours
A close look at one problem before you commit to anything bigger.
We pick one app and one main concern: a job that keeps failing, a fragile integration, an upgrade that's stuck, or an AI workflow you don't trust.
It covers up to four hours of investigation, conversation and write-up. You'll usually have it within five business days of the start date, once I have the access and information I need.
It's a focused look, not a full audit, and four hours won't always be enough to find the root cause. The findings are yours to keep either way, even if you take them to another engineer.
Fixed scope · planned after the assessment
Fix the agreed problem and leave the app easier to look after.
After the assessment I send a proposal with the scope, how we'll know it's done and the timeline. Nothing starts until you've agreed to it.
Typical examples: webhooks being processed twice, a background workflow that keeps failing, or an AI provider changing its response format and breaking a feature.
What the assessment found carries straight into the sprint, so nothing gets investigated twice.
Ongoing care
Monthly care starts once the assessment, and any urgent fixes, are done. Each plan covers one Rails app, including its background workers and integrations, with a fixed number of hours each month.
| Essential Care | Continuity Care | |
|---|---|---|
| Hours | 5 a month | 10 a month |
| Good for | A stable app that needs light upkeep | An app with a backlog, or integrations that change often |
| The hours cover | A regular maintenance review, bug fixes, selected updates and AI integration work, in the order we agree | |
| Keeping in touch | Written updates as I go, an optional short call each month, and a monthly note on what I did, the hours used and what's next | |
| Which plan? | We pick the right one together after the assessment. Ask me for details | |
Everything comes out of the hours: investigating, coding, testing, technical discussion, calls, write-ups and help with releases, including the monthly review and note. Scheduling and admin don't count.
We agree on priorities before I start. If something will take longer than the hours left, I'll explain the options and wait for your OK. Larger upgrades, new features and infrastructure moves get their own proposal.
Need more than the plan covers? I can take on extra work when I have time, and only with your approval. It doesn't come with reserved hours or emergency response.
On our agreed working days. A reply means I've looked at it and suggested a next step. It doesn't mean it's already fixed.
I work in your repository, your issue tracker and your deploy process.
You see the reasoning, the code and how it was checked before anything ships.
No long contract. Plans run month to month, and the hours each month are set aside just for your app.
This is scheduled support, not an on-call service. There's no 24/7 monitoring, no overnight incident response and no uptime guarantee. I check your error dashboards and alerts while I'm working on your app, but nobody is watching them around the clock.
How it works
Questions
Email me a few lines about your app and what needs attention. I'll reply with how I'd approach it and where I'd start. Scope, timing and the rest of the details are agreed in writing before any work starts.
Yes, after a look. I start by checking the Ruby and Rails versions, the dependencies, the tests and how the app is deployed. Big version upgrades are planned as their own project. They won't fit into a small monthly plan.
Yes, if it's mainly a Rails app and the assessment shows a sensible way forward. I judge code by how it behaves and how easy it is to maintain, whoever or whatever wrote it.
Of course. We'll agree on how changes get made and released. If changes made outside that process cause problems, sorting them out comes out of the monthly hours.
For 14 days after you accept a delivery, I'll fix any bug caused by that work that we can reproduce. New requests, unrelated bugs, and problems from later changes by other people or third parties are handled as new work.
We agree on access and data handling before I start, including whether AI tools can see your code or data. I only ask for the access the work needs. Please don't put passwords, production data or API keys in your first email.
I'm in UTC+8 and work mostly asynchronously, with some overlap with US and European hours that we agree up front. Working days, overlap hours, holidays and time off are all in the proposal before you commit. Start dates depend on availability.
What does it do, who relies on it, and what's taking up most of your time right now? I'll tell you honestly whether I can help and where I'd start.
Helpful to include: the app's URL, its Rails version if you know it, who's on the team, the main problem and your timing. I don't need repository access for the first conversation.