Dexterity: Git for Lawyers
Chief Technology Officer. September 2026 – Present.
Legal deals get negotiated over emailed Word documents. Each round is a fresh attachment, redlines get lost between versions, nobody is quite sure which draft is current, and the final signed contract gets reassembled by hand. It is distributed editing with no version control, on documents where a missed change can cost millions. Dexterity fixes that. The short version of what we build is Git for lawyers.
The problem
A contract negotiation is a multi-party editing problem. Counsel on both sides mark up the same document, trade it back and forth, and try to reconcile conflicting changes without a system of record. Software solved this for engineers twenty years ago with version control. The legal profession never got it. The cost is real: lost redlines, wrong-version executions, and hours of associate time spent diffing documents by eye.
What we build
Dexterity brings version control and a single source of truth to legal negotiation, and it does it inside the tools lawyers already live in rather than asking them to adopt a new place to work.
- Word add-ins, for both desktop and web, that track every change, keep every version reachable, and let counsel merge redlines cleanly instead of reconciling attachments
- An Outlook add-in and a Teams app, so the negotiation thread and the document stay connected to the deal instead of scattered across inboxes
- A cloud backend that holds the authoritative history of the document, manages permissions across parties, and carries the deal through to execution
Under the hood
The platform is a .NET 8 services layer over PostgreSQL, with an asynchronous document pipeline on Azure Functions, Service Bus, and Blob Storage. Document processing runs on OpenXML so changes are tracked at the structure of the document, not as opaque files, and execution integrates with DocuSign. The client surface is a set of Microsoft Office add-ins and a React application. It is a regulated, must-be-right domain, which is the kind of system I have spent most of my career building.
Where it is going
Managing the document is the floor, not the ceiling. The larger shift is from storing a deal as a stack of documents to modeling the deal itself: a connected map of the parties, agreements, conditions to close, tasks, and deadlines, with every fact traced back to the exact clause it came from. On top of that map sit agents that answer the question a deal team actually cares about, which is what is standing between us and closing, and back every answer with a citation. The version-controlled document is what makes that map trustworthy, because the history is real and nothing is a floating assertion.
Why this seat
I took the CTO role because it sits exactly where my work has always been: a security-critical, compliance-heavy domain where the software has to be right, built for professionals who cannot afford a tool that loses their work. Owning engineering, architecture, and technical strategy from this stage is the kind of seat you only get a few chances at, and this is the right domain to take it in.