Why I am Building AmtsGuide: Administration as a Data Product

Recently, I have broken down 4,000+ applications from the Berlin SPD in an AI system and have been able to observe the opportunities and risks. This was not about making politics, but a technical experiment. Sources, search, context, traceability. The question behind it was: How does AI turn a mass of text into something of value that enables decisions?

From this mindset, I am now starting with a new focus:

amtsguide.de

AmtsGuide is not a "AI solves bureaucracy" narrative for me, but rather the attempt to build something unglamorous in a clean way. To prepare administrative processes so that people can understand, execute, and locate them correctly. Not as bite-sized advice, how-to's, and FAQs, but as structured, citable information. Because anyone who has ever tried to reconstruct an administrative procedure solely based on administrative websites, PDFs, information sheets, forms, and scattered links knows how quickly an hour can turn into half a day.

What intrigues me about it is not "criticizing administration." It's the opposite: Administration is a highly complex operating system that functions daily, even though rules, responsibilities, exceptions, and local variations constantly intertwine. The problem is not that there is no competence there. The problem is that knowledge often does not exist as a usable product. It resides in documents, in established processes, in implicit rules. And it changes. Anyone who wants to digitize this quickly realizes: This is not a PDF problem. This is a data problem.

My desired vision is therefore simply formulated: Every city, every application, every rule as a data-capable structure. Not to automate everything, but to make it manageable. For citizens, for companies, for editorial offices, for systems. And yes, also for AI language models, which already provide answers today, whether we like it or not. If these models answer our topics, then they should be able to rely on clean sources and clear statements, instead of random forum snippets.

That is also a point where I am consciously cautious. AI is strong when it condenses, reformulates, structures, and provides code scaffolding. AI is weak when it is supposed to guarantee truth. That is precisely why the core of AmtsGuide is not "AI first," but "Truth first." We try to build the layer of truth outside the model: with sources, with clear assignment of responsibilities, with versioning, with a visible change status. I don't want to make big compliance promises that could backfire later. I would rather deliver a verifiable minimum that grows.

Human in the Loop

This leads to the most important design decision: Human-in-the-loop is our architecture. Content extraction, the decision on what we publish as fact, handling contradictions, maintaining local peculiarities: This is manual work. This is not backward, but what quality and responsibility mean in this context. AI comes afterward. It writes, structures, varies formulations, and helps us build the pipeline and the website. But it does not decide what is true.

And yes: I vibe-code. Completely. My infrastructure, my workflow, my templates, the website, the data pipelines, the automation steps—almost everything in the implementation is created in collaboration with AI as a pair programmer. For some, this might sound like playing around. For me, it is a very disciplined process: rapid iteration, small units, clear tests, clear acceptance criteria, version control. AI makes suggestions. I decide what gets adopted, and the responsibility remains with me. This is, for me, the productive way to build a system in a short time that would otherwise require a much larger team. At the same time, it's not a free pass. Vibecoding only works if you are willing to consistently check, limit, and document.

GovTech

Content-wise, I consciously start local and concrete. Berlin is now, at the end of 2025, the starting point. From January 2026, Hamburg and Munich will be added. Each new city necessitates clean data models, clear boundaries, reproducible QA steps, and an honest definition of what we know and what we (still) don't know. For me, this is where GovTech craftsmanship lies: not in the grand manifesto, but in the ability to reliably publish local reality.

An important point here is language. We deliberately work in simple, formal German. Not as a dogma, not as a DIN interpretation, but for utility. When people do not understand a process, they make mistakes. Mistakes cost time, money, nerves, and sometimes cause real damage. Comprehensibility is not "nice to have." It is a safety feature. At the same time, the goal remains to be SEO/GEO-compatible without falling into keyword spam. This means we use clear terms, consistent structures, short, quotable statements, along with source links. As tools, so that readers can do the right thing.

Even when it comes to timeliness, I want to formulate clearly. We provide central pages with a visible "Status" timestamp. This is not a real-time commitment, but the promise that if things change, we will make it visible in a short time.

Business model

Naturally, the question arises: How does this become a business model without turning into an address trading machine? AmtsGuide connects people with local service providers where users already have a concrete intention. Embedded in clear step-by-step processes, not in anonymous lists. I don't want auction logic, no click fee hell, no contract acrobatics. If it works, both sides benefit: users receive guidance and suitable help, providers receive predictable, high-quality inquiries. It is a simple model. But especially in a sensitive context, "simple and comprehensible" is often better than "maximally optimized."

AI and Responsibility

Why am I writing this publicly? Because I believe that when it comes to "AI in the public sector," we too often see only two extremes: euphoria or resistance. Neither is very helpful. I'm interested in the middle ground. Controlled use, clear boundaries, documented sources, human responsibility. I want to show how to build a real product with it, not just PowerPoints or questionable business models. And I also want to learn in the process. I will make mistakes. The difference will be whether you recognize them, correct them, and create a more stable system from them.

If you work in similar fields, I would appreciate concrete tips: good primary sources, typical misunderstandings, points where you regularly get stuck, or contacts with people who know the local reality and are willing to make it publishable. And if you're just reading along, that's fine too. In the coming weeks, I will write about how we model processes, how we handle timeliness, how we shape language, and why "AI plus craftsmanship" is the only serious option for me.