Vicente Reig Rincón de Arellano

  • Nearly two decades shipping software
  • Ruby and Rails across revenue, data, and product
  • New Relic · Apple · Atlassian

Fractional Ruby/Rails Lead Engineer

Your Rails application needs substantial work. Your team still has a product to ship.

I join engineering teams when an important Rails application has to change and the product still has to ship: a new revenue model, rising load, an architecture that no longer fits, or more change than the team can safely absorb.

I lead the consequential work, ship it with the team, and leave the team able to own what changed.

Email Vicente

The system still works. The conditions around it changed.

The technical problem rarely starts with Rails. The business changes first. Billing can no longer explain a charge. Background work outgrows its assumptions. Product changes cross too many system boundaries. An architecture built for the company you expected slows down the company you have.

The permanent team cannot stop serving customers while it redesigns the system.

That is when I am useful.

I take responsibility for the change, not just the recommendation.

I find the constraint, make the architectural and product calls, and work through implementation, tests, reviews, deployment, and production. I work inside the team's delivery rhythm because the change has to ship alongside everything else the company owes its customers.

The role is temporary. The decisions, operating context, and ability to continue remain with the team.

Selected work

Make revenue explainable

At Netlify, under- and over-billing incidents were eroding customer trust and creating support escalations. I replaced an ephemeral analytics table with an event-sourced Ruby ledger. Invoice lines can be replayed to their source events, and the Accounts & Billing team can own and extend the system.

Carry a revenue system through company change

At New Relic, I was responsible for the home-grown billing and subscription system in Ruby and Rails as the company moved from private to public. I later contributed to the service-oriented architecture work and evaluated vendors for its post-IPO replacement.

Scale the system and the way it ships

At Apple, I was directly responsible for customer-feedback tools built with Rails, Resque, Redis, and MySQL. We scaled them from 3 to 80 web instances and from 1 to 94 background workers. I also helped the team replace a fortnightly two-hour deployment meeting with smaller releases every day.

Recover Rails performance

At Staffing Referrals, some customer pages took more than 30 seconds to load or timed out. I worked through the Rails and PostgreSQL application and brought p75 response time below 500 milliseconds.

Why Ruby and Rails matter here

A mature Rails application contains years of product decisions: prices, permissions, workflows, exceptions, and promises made to customers. Its web requests, background jobs, data, integrations, and operating habits form one delivery system.

Changing that system safely takes more than framework knowledge. It takes judgment about what to preserve, what to simplify, and how to ship the next version without making the team afraid of the one it already has.

I work across high-throughput services and production web applications: event ingestion, billing and revenue infrastructure, background jobs, APIs, PostgreSQL, and the customer workflows around them.

I have worked in production software for nearly two decades, from Ruby billing at New Relic and Rails feedback systems at Apple to revenue, product, and event-driven systems. I still work in the code. I maintain DSPy.rb, an open-source framework for building LLM applications in Ruby.

Tell me what changed.

Send me what the application does, the work it needs, and what the team still has to ship. I will tell you whether I can help.

hey@vicente.services

Or connect on LinkedIn. Back to the homepage.