Rails upgrades that do not explode

A repeatable playbook from a decade of rescuing legacy Rails apps: how I sequence the upgrade, where teams usually get burned, and the tests that actually matter.

This is the studio bitácora — a working log rather than a polished publication. Entries get written when something is worth writing down: a strategy that cleared its evidence gate, a drawdown that taught me something, or an engineering decision I want to remember the reasoning behind.

The short version

Build small, ship it, keep it running, and write down what actually happened — including the parts that did not work. The full entry lives in the source repository; this page is the redesigned shell it renders into.

$ git log --oneline -1
a1b2c3d  rails upgrades that do not explo...

Want the rest? It is part of the open notes at hello@namilabs.ai.