Know the code, and the people, you're acquiring.

In an acquisition

• Technical due diligence. Architecture, code quality, security, scalability, and the debt that doesn't show up in a data room.
• Key-person risk. Who actually knows which systems, where knowledge lives in a single head, and what breaks if that person leaves after close.
• Team fit. How the engineering org you're buying will mesh with yours: practices, tooling, leveling, culture. Think of it as couples counseling for two engineering teams, before and after the merger.
• Integration. A realistic plan for the first months: what to combine, what to leave alone, and whom to keep.

Findings come in plain language for the deal team, not just the engineers.

Winding down or selling

Sometimes the hardest part of a transition is the handoff itself. Customer relationships, codebases, data, and the quiet operational knowledge that lives in a few people's heads. I help founders and small sellers get a fair read on what they have and move it cleanly, and compliantly, to the next owner.

How I work

Neutral and discreet. I can be engaged by the buyer, the seller, or both, and what I see stays between the parties.

Get in touch

If a deal or a transition is on your mind, send a note. It's a conversation, not a pitch.