A Rails advisory relationship that came back years later

The strongest thing I can say about this engagement isn't a quote. It's that the client came back.

The company

A Seattle clinical-genetics company building a genomics decision-support system — the kind of product that puts pharmacogenomic and genetic-risk information in front of physicians, inside the clinical workflow. The architecture was a Ruby on Rails front end talking to RESTful Java web services, with MongoDB behind it, running on AWS. Regulated healthcare data, so HIPAA was part of the picture from the start.

What I did

The first round was Rails best-practice and performance counsel for the external-facing product. The substantive questions were the ones you'd expect from a team getting ready to scale: which deployment platform, which web and app server, how to handle logging without letting the log collections eat the database. I worked through the MongoDB side in some detail — capped collections (and a then-current index bug worth knowing about), TTL indices, and archive-and-purge scripting to keep the hot collections small and fast. It was delivered as written guidance, not code I shipped.

Years later, the CEO reached out cold. They were planning a major Rails and Ruby upgrade and wanted my read on it. That led to a call and a working session with their dev team, and a low-volume advisory relationship that ran on for a while after — including a later debugging thread where a deploy stopped picking up CSS changes. I asked the diagnostic questions; the client found it himself (a manifest misconfiguration). Triage, not the fix. I'd rather tell it straight than dress it up.