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 at YPOG, a German law firm specializing in fund structuring and tax compliance. My work involves handling large volumes of data—investor information, contracts, regulatory filings—and building tools to make these workflows more scalable. This includes both traditional automation (data pipelines, document generation) and AI engineering (using AI where it actually makes sense).

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-Now

YPOG — Legal Data Scientist

I rejoined YPOG in 2023 as a "Legal Data Scientist." My role focuses on building tools for fund administration and tax compliance—areas where high-volume, specialized work requires both technical skills and understanding of the legal and regulatory context.

The work involves data engineering (handling investor data, contracts, regulatory filings), workflow automation, and AI engineering (integrating language models where they actually add value, not just for the sake of using AI).

Why This Blog

Off-the-shelf legal tech works for generic problems. But when you're dealing with specialized workflows—fund administration, multi-jurisdictional compliance, 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

My primary tools (very high-level): Python (for backend, data and AI related work), Postgres, SQLite, LanceDB (databases), and basic frontend technologies (HTML, CSS, a bit of htmx when needed). But I'm always trying new tools and frameworks—staying curious about what actually solves problems better.

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.