About Me

From Law to Code

The Short Version

I'm Matthias Enge, a lawyer-turned-developer working at the intersection of law, tax, and software. I practiced law for nearly a decade (corporate law, funds, insolvency, litigation) before realizing most of the repetitive work I was doing could be automated. So I learned to code.

Now I build custom software for legal and tax workflows. The work involves large volumes of data: investor information, contracts, regulatory filings. My job is to build tools that make these workflows more scalable, combining traditional automation (data pipelines, document generation) with AI engineering (using AI where it actually makes sense, not just for the buzzword).

This blog is where I document what I'm learning and building.

The Longer Version: How I Got Here

2004-2012

Law School & Training

I studied law at the University of Bayreuth, Germany (2004-2009) with a focus on commercial law. After passing my first state exam, I completed my legal clerkship (Referendariat) in Potsdam with stations at Hengeler Mueller and lindenpartners.

I then spent a year at the University of Sydney for an LL.M., which was less about the degree and more about enjoying life.

2013-2019

lindenpartners (Berlin)

I joined lindenpartners, Berlin, as an associate, focusing on corporate law, M&A, insolvency, and litigation. I worked on:

  • Class action litigation (coordinating hundreds of similar cases)
  • Corporate and real estate transactions
  • Fund governance (preparing and running shareholder meetings)
  • Insolvency litigation (creditor representation, avoidance actions)
  • Tax liability proceedings

The class action work taught me the value of organized, structured data. I managed hundreds of similar cases in Excel, building increasingly complex spreadsheets to track deadlines, documents, and client information.

Around 2018, I started learning Python to build a stronger foundation. Online courses, side projects, lots of Stack Overflow. What started as curiosity became clear: most legal workflows could be systematized with better data handling.

2019-2021

SMP (now YPOG): Fund Structuring

I joined SMP's fund structuring practice in Berlin, working on PE and VC fund structuring and VC financing rounds. I became Associated Partner in 2020.

2021-2023

Reset and Transition to Code

By 2021, I realized practicing law wasn't my passion anymore. So I decided to take a break, returned my law license, traveled, and regained my focus.

I also used the time to intensify my effort on learning to code. I built projects, read documentation, made every beginner mistake, and learned that coding isn't magic. It's just another skill. You practice, you get better.

2023-2026

YPOG: Legal Data Scientist

I rejoined YPOG in May 2023 as a "Legal Data Scientist" and stayed for three years, until July 2026. The role sat between engineering, legal, and IT, building tools for fund administration and tax compliance, where high-volume, specialized work demands both technical skills and an understanding of the regulatory context.

The work fell into a few broad areas:

  • AI systems for extracting, structuring, and evaluating terms from legal documents (contracts in particular).
  • Tax compliance tooling: integrating external accounting data, transforming it, and exporting back to standard formats.
  • Internal AI assistants for firm-wide knowledge retrieval and day-to-day support across legal and tax.
  • Prototype chatbots for practice-area-specific research and mandate support.

Under the hood that was backend and AI engineering: PostgreSQL plus vector databases (PGVector, ChromaDB, LanceDB), REST APIs, RAG pipelines, and data-extraction pipelines for unstructured legal documents, plus some TypeScript and Vue.js on the frontend. I ran the projects end to end, from requirements and architecture through implementation to the occasional client demo.

Since 2026

AI Engineer and Blogger ;-)

Why This Blog

Off-the-shelf legal tech works for generic problems. But when you're dealing with specialized workflows like fund administration, multi-jurisdictional compliance, or document processes with complex business rules, you need custom tools built by someone who understands both the legal domain and the firm's specific needs.

There's a lot of FOMO in legal tech right now. Firms think their problems will be solved if they just license the latest AI-powered tool. But most workflow problems aren't about missing features. They're rooted in how the firm organizes its data, structures its processes, and serves its specific client base.

Buying generic software for firm-specific problems is like trying to wear someone else's tailored suit: it might look similar, but it won't fit right.

The good news? Most of these problems don't require fancy AI. They can be solved with basic data engineering: cleaning messy Excel files, normalizing client data, building simple pipelines that turn structured inputs into consistent outputs. And when AI does make sense (like extracting terms from long-form contracts), it's about integration, not replacement.

This blog is where I share what I've learned about solving these problems: the technical patterns that work, the tradeoffs you'll face, and the mistakes I've made along the way.

What I Use

On the backend and AI side, my go-to tools are Python, PostgreSQL, and vector databases (PGVector, ChromaDB, LanceDB) for RAG and semantic search, and DSPy for structuring and optimizing LLM workflows. For quick prototypes I reach for TypeScript and Vue.js, with SQLite when I need a lightweight database. The backend is where I'm happiest, but I'm always trying new tools and frameworks, staying curious about what actually solves problems better.

For day-to-day development I lean heavily on AI coding tools: Claude Code, OpenCode, Pi, and GitHub Copilot. They've changed how I work, and a lot of what I write about here comes from putting them through their paces.

I prefer simple, maintainable solutions over complex frameworks. My goal is to "get off the ground" as fast as possible, so I often start with a minimal but working prototype that allows for quick iteration cycles.