We adopt the codebase as it is, no judgment about how it got here. The first phase is a read-and-stabilize pass, usually one to two weeks. We read the code at scale with AI tooling, map what the app actually does, find the live fires (the crashes, the silent data issues, the unpatched security holes), and put them out first. You get an honest written assessment: what is healthy, what is fragile, what is genuinely at risk, and what it costs to fix each.
From there we become the team. One named senior engineer fronts the relationship and stays on it, so there is no handoff to a junior who does not know your product. We backfill the missing test coverage so changes stop being scary, ship the fixes your users feel first, and only then talk about the bigger structural work. Old Rails version, no documentation, original author gone - that is the normal starting point for us, not a blocker.