Fix what slows your Rails team down.
Slow CI, flaky tests, an overdue Rails upgrade, code nobody wants to touch. Everyone agrees it matters. Nobody has six uninterrupted weeks to own it.
I’m Damian, a senior developer with 15 years in production Rails applications. I take that backlog off your team’s plate, with a codebase audit first and a six-week cleanup sprint after, delivered as small, well-explained pull requests your team can review in minutes.
Sound familiar?
-
The Friday fear
You deploy once a day, never on Fridays. CI takes forty minutes and nobody trusts the suite, so every merge feels like rolling the dice.
-
The green-by-rerun habit
Flaky failures have become folklore. The team reruns CI until it passes, and a red build no longer means anything.
-
The upgrade wall
It is not the version bump that scares you. It is the long tail, an abandoned gem, monkey patches on Rails internals, point releases with undocumented changes, and no coverage to tell you what broke.
-
The code nobody wants to touch
A few models know about everything, saving one record triggers an invisible callback chain, and specs are so coupled to implementation that a refactor means rewriting tests.
-
The app that slows down as it grows
N+1 queries, missing indexes, exports that load the whole table, a Sidekiq queue that drains slower than it fills.
-
The never-ending roadmap
Features get more expensive to build because of legacy code. The product team waits, the technical backlog stays a list of vague intentions, and maintenance always loses.
Hiring another developer will not remove the bottleneck.
A new hire inherits the same CI, the same flaky tests, the same upgrade debt. They spend their first months learning to work around it, like everyone else. Candidates read the Gemfile too, and an old Rails version makes hiring slower.
It is getting worse this year. Coding agents make your team ship more, and more pull requests hit the same slow CI, the same flaky suite, the same tangled models. Agents amplify whatever system they are dropped into: on a clean codebase they multiply your team, on a tangled one they write legacy code faster.
A fast, reliable, well-structured codebase is now the limit on how much your team can ship, with or without AI. That is the piece of work I take on.
How it goes, step by step.
From the first call to the merged pull requests, with your team in control at every step.
-
1
A free 15-minute discovery call
You tell me what your team keeps postponing and what slows down a release. We decide whether an audit makes sense.
-
2
You give me access to the codebase
Read access is enough to start. We agree on the tools allowed and the access rules before I open the repository.
-
3
I audit the application
I read the codebase and your development workflow, measure what can be measured, and write the plan.
-
4
We prioritize with your team
A call with your technical lead and developers to walk through the findings and choose what the sprint takes on first.
-
5
We agree on the rules of the project
Together with your Rails developers we fix the conventions you want applied from now on. Every pull request follows them.
-
6
Pull requests start, with a living document
One document, updated continuously, holds the audit, the plan and the progress of every pull request, created, in review and merged.
Pull requests your team will enjoy reviewing.
Cleanup work fails in review, not in implementation. Seventy pull requests dumped on a busy team is a backlog, not a gift. I learned that the hard way, so the sprint is built around the question every CTO asks next: “yes, but we still have to review all of this.”
Every pull request I open ships with a short visual report, generated by the tooling I bring to the sprint. Your reviewer understands the change in minutes instead of reading every diff line.
| What you are about to ask | What every pull request includes |
|---|---|
| “We still have to review all of this.” | A one-page visual report attached to each pull request. What changed, why it matters, what it does not touch, with the before-and-after numbers when they exist. Review in minutes, not hours. |
| “How do we know it was actually tested?” | The tests added or changed, the commands run and their results, and anything that still deserves a human eye, listed in the report. Nothing to guess. |
| “Our team cannot absorb seventy PRs in a week.” | Small, single-purpose pull requests, in batches sized to your team’s week. If review falls behind, I slow down and prepare the next batch instead of piling up. |
| “Who pushes to production?” | You do. Every change lives on its own branch and its own pull request. I never push to your main branch and I never deploy. Someone on your team approves and merges, every time. |
| “How do we follow what is going on?” | A shared plan, visible every day, listing what is in scope, in progress, waiting for review and done. Your technical lead sees the same board I do. |
Stop booting Rails for 1,400 unit specs
Specs under spec/lib and spec/services no longer load rails_helper. Nothing changes in application code.
- Unit suite
6m 48s1m 12s- Files touched
- 38
- Behavior changes
- none
- Full suite green, three runs
- Coverage unchanged at 91%
- Needs a reviewer eye on spec/support/time_helpers.rb
Your code stays between you, Anthropic and OpenAI.
I work with Claude Code and Codex on enterprise plans, and with Cursor on a business plan. Those plans mean no training on your data and no retention on the provider side. Your code is never sent to any other server, and we agree on the access rules before I open your repository.
- Claude Code
- Codex
- Cursor
Whatever your Gemfile looks like, I have probably met it.
What is always in my backpack. Something missing? Tell me on the call.
- Framework Rails 5+ · Ruby 2.7+
- Databases PostgreSQL · MySQL · MongoDB · Redis · Elasticsearch
- Background jobs Sidekiq · Solid Queue · Good Job · Delayed Job · Resque
- Testing RSpec · Minitest · FactoryBot · Fixtures · Custom
- Authentication Devise · OmniAuth · Custom
- Authorization Pundit · CanCan · Custom
- Frontend JavaScript Hotwire · Turbo · Stimulus · Vue.js · React · Custom JS
- Frontend CSS Tailwind · Bootstrap · Material Design · Custom CSS
- Asset pipelines Importmap · Sprockets · Propshaft · Webpacker
- APIs GraphQL · REST · RPC
- Deployment Docker · Kubernetes · Kamal · Heroku · Render · AWS · Azure · GCP · Bare metal
- CI / CD GitHub Actions · GitLab · Others
- File uploads Active Storage · CarrierWave · Shrine · S3 · Custom
- Admin panels ActiveAdmin · Administrate · RailsAdmin · Custom
- Monitoring Sentry · Bugsnag · Datadog · New Relic · Others
15 years inside production Rails applications.
I shipped my first website in 2006, made my first open source contribution in 2010, and have worked mostly on Ruby on Rails since 2011.
- 2026 A contribution merged into RailsPull request #56967 in the Rails repository
- 2023–2026 kelvin, a large Rails monolithGrew a new Rails application into a 130-table monolith serving enterprise customers in a regulated industry
- 2017–now Localtower, a Rails Engine for database migrationsBuilt to support applications from Rails 5.2 to Rails 8 and featured in Ruby Weekly
- 2017–2019 Ruby and Sidekiq at scalePostgreSQL, Sidekiq Enterprise, Kubernetes, APIs and a CI pipeline reduced from 45 to 4 minutes
- 2017 Rails due diligence for the Loco2 acquisitionA quality audit of a large, business-critical Rails application, read and assessed in days
- 2013–2016 Geeksters, one of the first Ruby dev shops in MoroccoWe built The House Of Geeks in Agadir, where I taught Ruby on Rails and grew the team from 2 to 15 full-stack developers
- 2011–2020 HashtagBattle, my first Rails product in productionScaled to thousands of users per minute and maintained for eight years
A few practical questions.
- How much time will our team need?
- A technical contact, a kickoff to share context, and regular time to review pull requests. We size the review load to your team before starting. Every pull request is written to be reviewed in minutes, not hours.
- Can you help while we are recruiting?
- Yes. The audit shows what is slowing your current team down. The sprint clears an agreed backlog while your hiring process continues, so your next developer starts on a cleaner codebase.
- Do we have to buy the sprint after the audit?
- No. The audit is a standalone engagement with a standalone deliverable. Many teams use the plan internally.
- Do you push to production?
- No. Every change is a dedicated branch and pull request. Nothing is merged without someone from your team approving it.
- What if our priorities change during the sprint?
- We review the plan together every week. Scope is fixed at the start, but we can swap a priority if something more valuable appears, within the six weeks.
- Do you use AI coding tools?
- Yes, extensively, and openly. Standard tools only, inside the access rules we agree on. I review every change before it reaches your team.
- How do you handle access and confidentiality?
- Read access for the audit, a dedicated account with the permissions you choose for the sprint, and an NDA when you need one. Nothing is sent to a tool you have not approved.
- Can we do everything remotely?
- Yes. GitHub, Slack and video calls. I am based in Madrid, I work in English, French and Spanish, and I am available on US working hours too.
Two ways to start.
Rails Codebase Audit.
Know what to fix first.
You receive
- A concise assessment of the main sources of friction, with examples from your application.
- A prioritized action plan: what to address first, why, and what it depends on.
- Baseline measurements where available, with gaps in evidence made explicit.
- A proposed scope for a six-week sprint, with the time needed from your team.
- A walkthrough of the findings with your technical lead.
Audit + Cleanup Sprint.
Six weeks to act on the priorities.
Based on the audit, we agree on scope, success criteria and a fixed fee before starting. Not six weeks of one developer’s time, but six weeks of a senior engineer running coding agents in parallel on your codebase, with every change reviewed by a human before it reaches your team.
Typical priorities
- CI and test speed: slow steps, boot time, parallel workers, a shorter feedback loop.
- Test reliability: flaky tests removed for good, order and state leaks fixed, coverage where the next change needs it.
- Ruby, Rails and gem upgrades: a staged, tested path, including the abandoned gems and monkey patches that block it.
- Targeted refactoring: the models, callbacks and controllers that keep slowing development, protected by characterization tests.
- Application performance: specific request, query and background-job bottlenecks, with before-and-after measurements.
What would you like your Rails team to stop losing time on?
Tell me what keeps getting postponed, what slows down a release, or what your team is tired of working around. A short description of your application and your biggest bottleneck is enough to start.
Fluent in English, French and Spanish. Based in Madrid, available on US working hours too.
