What I Learned Rebuilding a Live Product From Someone Else's Code

A previous technical lead had left. I did a trial audit task: trace the data flow, find where things silently break, write it up honestly. That was supposed to be the whole ask.

I ended up rebuilding most of the codebase to production grade, and became the person who owns it end to end.

The gap between "it runs" and "it's trustworthy"

The system worked, technically. But working and trustworthy are different bars. A matching system that occasionally sends the wrong recommendation doesn't just have a bug. It damages the one thing the whole product depends on: someone believing the system has good judgment about their life.

That reframed how I think about reliability. It isn't a performance metric. It's the actual product.

Engagement is the enemy of trust

The clearest thing I learned building this: most consumer software is optimised to keep people looking, not to serve them well in one sitting. More sessions, more taps, more time in app. That's the metric that gets optimised, almost by default.

But if what you're selling is judgment, a good recommendation, a considered introduction, a decision someone can trust, then engagement time is a cost rather than a win. The best outcome is often one good interaction, after which the person goes and lives their life.

What I'd tell someone inheriting a codebase

Read the data before you read the code. Trace one real user's journey through the system by hand before you touch a single file.

Most of what looks like a technical decision is a trust decision wearing a technical costume.