Out of one head, into a team

Turned a one-engineer dependency into a documented system run by a real team

Tap N Go sells the RFID wristbands, cards, and kiosks that make events cashless — fairs, festivals, parks, cruise ships. Behind that is a mature Ruby on Rails app on AWS, moving real money and gating access while the event is happening. It worked. The problem was that essentially one person knew how it worked, how it deployed, and how to fix it when something went wrong mid-event — and he was leaving. On a revenue-critical, live system, that is the quiet kind of risk that only becomes loud at the worst possible moment.

What was done

I went after the knowledge before it walked out the door. I set up recurring sessions with the departing engineer, got the app running locally, and learned the deployment process and how to troubleshoot production through the AWS tooling. The durable part was that those sessions became onboarding documentation — written from real work on the real system, not a parting brain-dump nobody trusts. The point was never a document for its own sake; it was that the next person could deploy, debug, and reason about the platform without him in the room.

That handled continuity. The other half was the future. In parallel I interviewed longer-term engineers for the actual new-feature work and hired a few who are still there, onboarding them into the same documentation while production kept running. Through all of it nothing broke during events. Once the team was in place and shipping, I stepped back.

The result

What had been one engineer’s head is now a written, runnable system owned by a team. They keep events running and they build new features on top — the dependency is gone, and the platform reads as something a group maintains rather than something one person remembers. The handoff was uneventful, which is exactly the outcome you want.

One reflection

The best documentation isn’t written after the expert leaves — it’s written while he’s still there and the work is real. Capturing knowledge during an actual deploy or an actual production fix produces something the next engineer believes, because it survived contact with the live system. The hard part was never the Rails app; it was making sure the understanding of it didn’t leave with one person. An uneventful departure is a strange thing to pitch up front — there’s no dramatic save to point at — but on a platform that takes money in real time, boring is the whole point, and it’s the hardest outcome to promise before you’ve earned it.