Registercheck

The platform

Registercheck turns the German commercial register into searchable, structured data: profiles for 5.8 million companies from 118 register courts, the people behind them, register documents, shareholder structures, financial figures and change monitoring. It is used by M&A, compliance, legal and finance teams, through the web app, a REST API, and an MCP server for AI assistants.

My role

I joined Openlaw in April 2026 on beglaubigt.de's data platform, became temporary lead engineer for firma.de in June, and have been lead engineer for Registercheck since September 2026. I own the whole stack: the Next.js app, the Python services, the extraction pipeline and the infrastructure. Product direction comes from the CPO; architecture and delivery are mine.

What I shipped in the first six weeks

• Took over and stabilised the platform. Audited the inherited system end to end before changing anything, then fixed company identity matching on court and register number. That merged 19,487 duplicate company pairs with zero orphaned rows.
• Public REST API v1, spec-first. The OpenAPI contract came before the code. It is gated by strict lint rules, domain rules for naming and ownership, and a 19-case mutation suite that must catch every deliberate contract break. Before launch I audited every live operation against 260 randomly sampled companies.
• Developer docs at docs.registercheck.de, generated from the same contract. The build fails if the backend drifts from the spec.
• Auth moved to a self-hosted Better Auth service. User IDs were preserved and social-login accounts were pre-linked, so those users signed in on day one without a password reset.
• Workspaces and billing. Multi-tenancy rolled out in order (expand, backfill, sweep sessions, enforce), followed by workspace billing on a credits ledger of our own.
• Monitoring and alerts. Company change monitoring with per-watch delivery by email and signed webhooks.
• A remote MCP server with OAuth 2.1, so AI assistants can search and read the register through 12 tools over the public API.
• Frontend. Migrated Next.js 14 to 16 and fixed sitemaps covering about 10.8 million profile URLs.

Re-platforming LLM extraction in a day

The pipeline that reads register documents depends on language models. When it had to move to new models on short notice, I didn't pick replacements by reputation. I replayed real production requests, measured the old model's own noise floor first, and had disagreements adjudicated blind against a rubric.

• People extraction: the new setup was judged better on 30% of compared parts and worse on 0.9%, inside a 0.8% noise floor, at about 72% lower cost per call.
• Shareholder lists: 49% of scanned pages turned out to be rotated. Uprighting them and reading the PDF directly gave 143 of 150 lists exactly right on a holdout, with zero fabricated entries.

All of it rolled out the same day behind canaries, with a rollback script for every deployment.

Accuracy I can put a number on

• Financial statements. Balance-sheet figures extracted from published annual accounts, with rules grounded in the German commercial code. On a blind audit of 150 fresh statements, 99.62% of values were correct (lower bound 99.28%) and completeness was 95.95%.
• Founding dates. The first version failed its holdout, so it didn't ship. With guards added it certified at 1 wrong in 413 (95% upper bound 1.34%).
• Decision questions. In a benchmark of six production decisions with a control arm, most of the accuracy gain came from asking sharper questions, not from a bigger model.

How the codebase changed

• A modular monolith with layer contracts enforced in CI, and a shrink-only exception list.
• 36 database functions and 11 triggers that existed only in production are now versioned in the repo.
• About 40,000 lines of dead code removed with the full test suite green; around 19,000 tests now gate CI.
• When a full rebuild was proposed, I wrote an evidence-based assessment instead: rebuild about a quarter, keep the extraction pipeline and the data.

What I took from it

• Measure the noise floor before you compare models. Without it, a "better" model is often just a different coin flip.
• A check can answer a different question than the one you asked. Most of my wrong conclusions came from verification steps that returned a confident reading about the wrong thing.
• Ship the boring guarantees first. Contracts, IDs that never change, and rollback scripts are what make it safe to move fast later.