In 6 Tagen zum eigenen CRM: Was KI-gestützte Entwicklung für Architekten bedeutet

SoloCRM ist ein selbst gehostetes CRM für Freelancer, gebaut mit .NET 10, Blazor und Claude Code. Der Code ist offen, die Erkenntnisse sind es auch.

Warum ein eigenes CRM?

Als Freelancer brauche ich drei Dinge: Kein Follow-up darf verloren gehen. Ich will meine offenen Anfragen auf einen Blick sehen. Und ich will zu jedem Kontakt die komplette Historie haben. HubSpot Free kann das im Prinzip. Mir fehlte aber die Kontrolle über meine Daten, und ich wollte verstehen, wie die zentralen CRM-Mechaniken von innen funktionieren: Timeline, Audit, Suche, Webhooks.

SoloCRM hat deshalb drei Aufgaben. Es ersetzt meine bisherige Lösung im Tagesgeschäft. Es ist ein Lernprojekt. Und es ist ein Referenzprojekt, das ich öffentlich zeigen kann.

Was SoloCRM kann

Die Pipeline zeigt alle offenen Projektanfragen als Board mit Drag & Drop. Jede Anfrage hat ein Preismodell (Stunden-/Tagessatz, Festpreis, Retainer) und eine Laufzeit. Aus beidem berechnet SoloCRM live den Wert, und das Board summiert ihn je Phase.

„Heute“ beantwortet jeden Morgen die Frage, was ansteht. Die Ansicht zeigt fällige Aufgaben und Anfragen, bei denen es zu lange keine Aktivität gab. Damit erfüllt SoloCRM sein wichtigstes Ziel: Kein Follow-up geht verloren.

Die Detailansicht einer Anfrage zeigt die Timeline: Notizen, Anrufe, Meetings, E-Mails, Aufgaben und lesbare Änderungen wie „Phase: Beworben → Im Gespräch“ oder „Preis: 95 €/h → 105 €/h“. Eine Organisation sieht zusätzlich die Einträge ihrer Kontakte und Anfragen.

Die Command Palette (Ctrl/Cmd + K) ist der schnellste Weg durch das System. Sie sucht tippfehlertolerant über Kontakte, Organisationen und Anfragen. Ein neuer Kontakt mit Notiz ist damit in unter 30 Sekunden erfasst. Das war eines der Erfolgskriterien.

Dazu kommen CSV-Import (mit Vorlagen für HubSpot-Exporte), eine REST-API mit API-Keys und signierte Webhooks, zum Beispiel für n8n-Workflows. Für den Datenschutz gibt es DSGVO-Auskunft, endgültige Löschung, Zwei-Faktor-Anmeldung und Passkeys.

Die Architektur: bewusst unspektakulär

Ein Single-User-CRM braucht keine Microservices. SoloCRM ist ein modularer Monolith mit Vertical Slices aus vier Projekten: Domain, Application, Infrastructure und Web. Die Abhängigkeitsrichtung ist fest. Die Domain kennt nichts, Application kennt nur die Domain, und Web ist der Composition Root.

Drei Entscheidungen prägen den Code:

1. Ein Use Case, eine Datei. Command, Result, Validator und Handler liegen zusammen in einer statischen Klasse. Wer verstehen will, was „Kontakt anlegen“ tut, öffnet eine Datei. Es gibt kein MediatR, kein AutoMapper und kein Repository-Pattern. Handler nutzen den DbContext direkt, das Mapping ist explizit.

2. Querschnittsthemen gehören in Interceptors. Audit-Einträge und Zeitstempel setzt ausschließlich ein EF-Core-Interceptor, kein Handler fasst CreatedAt an. Domain Events werden in den Entitäten gesammelt und im selben Commit in eine transaktionale Outbox geschrieben. Ein Hintergrunddienst verarbeitet sie und verschickt die Webhooks. So geht kein Event verloren, und es wird auch keines für eine Transaktion verschickt, die danach fehlschlägt.

3. Regeln, die ein Test durchsetzt. Die Schichtregeln stehen nicht nur in einem Dokument. Ein Architekturtest prüft sie bei jedem Build. Dazu kommen Warnings as Errors, aktivierte Nullable-Prüfung und Central Package Management. Zum Ende des MVP lag die Zeilenabdeckung bei 99,6 % in der Domain und 98,5 % in der Application. Ein hartes Gate in der CI gibt es noch nicht.

Der Stack: .NET 10, Blazor (Interactive Server) mit MudBlazor, Minimal APIs, EF Core 10 mit PostgreSQL, Testcontainers für echte Integrationstests, GitHub Actions und Deployment über Coolify.

Der Praxisbericht: Wie die Zusammenarbeit mit der KI ablief

Gebaut habe ich SoloCRM mit Claude Code. Ich war Product Owner, Architekt und Human in the Loop. Der Ablauf war in jeder Iteration derselbe:

1. Spezifikation zuerst. Die SPEC enthält Vision, bewusste Nicht-Ziele, Domänenmodell, User Stories mit Akzeptanzkriterien und einen Iterationsplan mit Definition of Done.
2. ADRs als bindende Leitplanken. Abweichungen sind nur mit einem neuen ADR erlaubt. Das gilt für mich genauso wie für die KI.
3. Eine CLAUDE.md mit Regeln, die nicht verhandelbar sind, zum Beispiel „kein MediatR“, „Blazor-Komponenten greifen nie direkt auf den DbContext zu“ und „IDs sind UUIDv7“.
4. Sechs kurze Iterationen, jede mit eigenem Dokument: vom Walking Skeleton über Kerndomäne, Timeline, Suche und Integration bis zu DSGVO und Politur.

Die KI schrieb den Code, ich habe entschieden, geprüft und korrigiert. Dass das so gut funktioniert hat, liegt an den schriftlichen Leitplanken. Sie machen Entscheidungen nachvollziehbar und prüfbar.

Wo der Mensch eingreifen muss

Drei Beispiele aus dem Projekt zeigen, warum ich die Architekturverantwortung nicht abgeben würde:

Audit gegen DSGVO. Der Audit-Interceptor schreibt beim Löschen alle bisherigen Feldwerte ins Änderungsprotokoll. Für die Nachvollziehbarkeit ist das richtig. Für die DSGVO-Löschung ist es genau falsch, denn dann landen die personenbezogenen Daten im Audit. Dazu sieht der Interceptor Datenbank-Cascades nicht, die Audit-Einträge mitgelöschter Activities blieben also stehen. Gelöst habe ich das in Iteration 6 mit einer endgültigen Löschung, die das Änderungsprotokoll anonymisiert. Solche Querschnittseffekte findet man nur, wenn man das Gesamtsystem im Kopf hat.

Ein technisches Feld mit fachlicher Wirkung. Anfragen kannten zunächst nur das technische CreatedAt. Nachträglich erfasste Anfragen erschienen dadurch zu neu und wurden zu spät als „eingeschlafen“ erkannt. Die Lösung war ein eigenes Eingangsdatum. Wer Zeitstempel zweckentfremdet, zahlt dafür später.

Betriebliche Lücken. Das Volume mit den Data-Protection-Keys ist betriebskritisch, denn es hält Login-Cookies und Webhook-Secrets. Die Postgres-Backups erfassen es aber nicht. Das ist in den ADRs als offener Punkt dokumentiert. Eine KI baut Features zuverlässig, aber auf solche Lücken muss man erst kommen.

Das Ergebnis

Der Aufwand lag bei rund 6 Tagen. Ohne KI hätte ich für denselben Umfang ein Team von etwa fünf Personen über rund sechs Sprints geschätzt. Für mich ist das ein Gamechanger für individuelle Softwareentwicklung. Der Hebel liegt aber nicht darin, dass die KI schneller tippt. Er liegt darin, dass ein erfahrener Architekt seine Entscheidungen so präzise festhalten kann, dass die KI sie zuverlässig umsetzt.

Offen, aber mit Bedingungen

SoloCRM steht unter der AGPL-3.0. Jeder darf es selbst hosten, anpassen und daraus lernen. Wer es dagegen als geschlossenen Dienst anbieten will, muss seine Änderungen zurückgeben.

Als Nächstes steht eine Nextcloud-Synchronisation über CardDAV und CalDAV an. Das Backlog liegt in Jira, die Konzepte stehen in der SPEC.

Code, Spezifikation und ADRs: github.com/guido-altmann/solocrm