Hattest du schon mal ein solch überwaltigend wirkendes Projekt, bei dem man dich bittet, ein benutzerdefiniertes CRM von Grund auf zu bauen, und du denkst: „Das ist unmöglich"? Ich hatte diesen Moment vor zwei Jahren mit einem Kunden, der sein CRM in nur 14 Wochen fertig brauchte. Kein typischer Zeitrahmen. Aber hier ist der Punkt: Mit unserem 5-Phasen-Playbook war es nicht nur machbar, sondern überraschend reibungslos. Stack Overflow und Postman waren meine täglichen Begleiter. Und ja, ich habe unterwegs mehr als nur ein paar Lektionen gelernt.
Phase 1: Discovery und Scoping (Wochen 1–2) In der ersten Phase geht es darum, die genauen Anforderungen zu verstehen. Wir sprechen mit Ihnen und Ihrem Team, um herauszufinden, was Sie brauchen. Ziel ist klar: Wir legen fest, welche Funktionen wichtig sind und welche Ressourcen wir benötigen. Das Team analysiert vorhandene Systeme und identifiziert mögliche Hürden. Gleichzeitig definieren wir den Zeitplan und das Budget. Alles transparent, alles dokumentiert. Am Ende dieser Phase haben Sie einen klaren Plan. Der zeigt genau, was kommt.
Die meisten CRM-Projekte scheitern, bevor eine einzige Codezeile geschrieben wird. Ich meine das ernst. Das Scheitern passiert in einem Konferenzraum, normalerweise an einem Whiteboard, wenn alle vage Anforderungen nicken und niemand die unbequemen Fragen stellt.
Bei diesem speziellen Projekt—einem mittelgroßen Logistikunternehmen in Birmingham mit etwa 80 Mitarbeitern—verbrachte ich die ersten zwei Wochen fast nur zuhörend. Workshops. Aufgezeichnete Zoom-Calls. Ein gemeinsames Notion-Dokument, in das Stakeholder jeden Workflow eintragen konnten, den das CRM handhaben sollte. Das Dokument wuchs auf 47 Seiten. Vieles davon war widersprüchlich. Das ist eigentlich in Ordnung. Widersprüche in einem Discovery-Dokument sind kostenlos; Widersprüche, die man in Woche elf entdeckt, kosten dich einen Sprint und eine Kundenbeziehung.
Was du eigentlich abbildest
Das Ziel in der Discovery-Phase ist nicht, jedes Feature zu erfassen. Es geht darum, die Datenbeziehungen und Benutzerrollen zu kartieren, die später jede architektonische Entscheidung beeinflussen. Ich nutze Whimsical für Flussdiagramme. Schnell und teilbar. Clients können kommentieren, ohne sich registrieren zu müssen.
Am Ende der Woche 2 brauchst du vier Deliverables, die festgelegt sind:
- Eine priorisierte Feature-Liste, aufgeteilt in MVP und Post-Launch-Buckets
- Ein Entity-Relationship-Überblick (noch keine vollständige Schema, nur die Substantive: Contacts, Deals, Pipelines, Tasks)
- Benutzerrollen-Definitionen mit Berechtigungsstufen in einfachem Englisch geschrieben
- Ein abgezeichneter Zeitplan mit benannten Meilensteinen, keine vagen Phasen
Das letzte Punkt ist nicht verhandelbar. „Phase 2 abgeschlossen" bedeutet nichts. „Contact-Import und rollenbasierter Zugriff live in Staging bis Tag 28" bedeutet etwas.
---
Phase 2: Architektur- und Tech-Stack-Entscheidungen (Woche 3)
Eine Woche. Das ist alles, was ich dieser Phase gebe, weil ich Teams gesehen habe, die einen Monat lang in Architektur-Debatten verschwunden sind und nichts ausgeliefert haben.
Für dieses Projekt bestand der Stack aus: Node.js mit Express auf der Backend-Seite, PostgreSQL für die Datenbank, React auf der Frontend-Seite, und das Ganze wurde auf verwalteten Kubernetes auf DigitalOcean bereitgestellt. Wir haben Prisma als ORM verwendet, weil sich das Schema schnell ändern sollte und Prismas Migrationworkflow ist dafür wirklich gut geeignet.
Ehrlich gesagt ist der Stack weniger wichtig, als Menschen denken. Was mehr zählt, ist:
- Wird jeder Entwickler in diesem Projekt diesen Stack ohne steile Lernkurve kennen?
- Unterstützt die Architektur das Berechtigungsmodell, das du in Phase 1 festgelegt hast?
- Kannst du in Woche 10 einen neuen Entity-Typ (z. B. „Lieferant") hinzufügen, ohne die Auth-Layer neu zu schreiben?
Bei diesem dritten Punkt bin ich schon vorher auf die Nase gefallen. 2021 hatten wir bei Seahawk Media ein SaaS-Projekt, bei dem wir Multi-Tenancy in Woche 9 draufgesattelt haben. Es hat vier Tage gedauert, um etwas zu ändern, was hätte eine Entscheidung am ersten Tag sein sollen. Nie wieder.
Für die Authentifizierung fahre ich standardmäßig mit Auth0, es sei denn, es gibt einen triftigen Grund, das nicht zu tun. Es behandelt die Edge Cases (Passwort-Zurücksetzen, MFA, Social Login), an denen Junior-Entwickler scheitern.
---
Phase 3: Core Build Sprint (Wochen 4–9)
Sechs Wochen. Das ist der Maschinenraum. Und wenn dein Scoping solide war, ist diese Phase eigentlich der unkomplizierteste Teil des ganzen Projekts.
Ich habe das in zwei dreiwöchige Mini-Sprints aufgeteilt mit einer harten internen Review in der Mitte.
Sprint A: Data Layer und API (Wochen 4-6)
Nichts berührt das Frontend, bis der API-Vertrag vereinbart ist. Punkt. Ich dokumentiere jeden Endpoint in Postman, bevor ich einen Controller schreibe – das klingt mühsam, spart aber etwa zwei Wochen an „Moment, was gibt dieser Endpoint zurück?"-Gesprächen später.
Das Datenbankschema bekommt hier seinen ersten echten Durchlauf. Bei CRMs sind die Tabellen, die immer unterschätzt werden, die Activity-Log-Tabelle und die Custom-Fields-Tabelle. Jeder Client möchte Custom Fields. Eine flexible custom_field_definitions-Tabelle von Anfang an richtig aufzubauen kostet etwa vier Stunden. Sie in Woche 11 zu improvisieren ist ein Albtraum.
Sprint B: Frontend und Workflows (Wochen 7-9)
React mit TanStack Query für Server-State-Management. Ich habe 2022 bei einem kleineren Projekt versucht, nur mit useEffect und lokalem State zu arbeiten. Das mache ich mir nie wieder an. TanStack Query handhabt Caching, Background Refetching und Optimistic Updates so, dass CRM-Interfaces sich schnell anfühlen, ohne Heldentaten.
Für die UI-Komponentenschicht haben wir shadcn/ui bei diesem Projekt verwendet. Es ist keine Komponentenbibliothek im klassischen Sinne; du besitzt den Code, das bedeutet, du kannst ihn tatsächlich anpassen, ohne gegen die Bibliothek zu kämpfen. Bei einem CRM mit Pipeline-View, Kontaktetabelle und Task Board ist diese Flexibilität wichtig.
Eine Sache, die in diesem Sprint immer durchfällt: Empty States. Ein CRM ohne Daten sieht kaputt aus, wenn du keine Zero-State-Screens designt hast. Bau sie früh. Clients führen Stakeholdern Demos mit leeren Datenbanken vor und erste Eindrücke bleiben hängen.
---
Phase 4: Integrationen und Datenmigration (Wochen 10-11)
Hier machen die meisten Agenturen den Fehler, zu niedrig zu kalkulieren und unzureichend zu planen. Ich habe das jedes Mal gesehen.
Der Logistik-Kunde aus Birmingham benötigte Integrationen mit seinem bestehenden Xero-Accounting-Setup und einer älteren Salesforce-Instanz, die er gerade ablöste. Zwei Wochen klingen eng. Das waren sie auch, aber wir haben es geschafft, weil wir die Integrationspunkte bereits in Phase 3 vorgesehen hatten.
Speziell für die Salesforce-Migration haben wir ihre Bulk API 2.0 genutzt, um die Daten zu extrahieren, dann haben wir sie durch ein Node-Skript laufen lassen, das ihre Feldstruktur auf unsere gemappt hat. Das Skript brauchte einen Tag zum Schreiben und drei Tage zum Iterieren, weil Salesforce-Daten fast nie so sauber sind, wie Kunden glauben. Budget für Datenbereinigtung ein. Immer.
Ein paar Dinge, die ich überprüfe, bevor ich eine Integration als „fertig" bezeichne:
- Fehlerbehandlung: Was passiert, wenn die Third-Party-API ausfällt?
- Webhook-Idempotenz: Kannst du sicher dieselbe Veranstaltung zweimal verarbeiten, ohne Datensätze zu verdoppeln?
- Rate Limits: Befindest du dich darunter unter realistischer Last?
Die Xero-Developer-Dokumentation ist eigentlich anständig, für das, was es ist. Der OAuth 2.0-Flow ist gut dokumentiert und ihre Sandbox-Umgebung funktioniert zuverlässig.
---
Phase 5: QA, Hardening und Übergabe (Wochen 12–14)
Drei Wochen QA klingt großzügig, bis man mittendrin steckt.
Woche 12 ist strukturiertes Testen. Ich gebe dem Kunden ein ClickUp Board mit jedem Test Case als Task geschrieben, er testet, markiert es, hängt ein Loom an, wenn etwas bricht. Das bringt echte Nutzer durch echte Flows, was immer Dinge aufdeckt, die ein von Entwicklern durchgeführter Test übersieht. Jemand wird versuchen, 4.000 Zeichen in ein „Notizen"-Feld zu kopieren. Jemand wird eine CSV mit Smart Quotes importieren. Du willst das jetzt finden.
Woche 13 ist der Fix Sprint. Keine neuen Features. Nur Bug Fixes und Performance-Arbeit. Ich laufe Lighthouse gegen jede Key Page. Ich führe auch k6 Load Tests gegen die API durch, nicht weil der Kunde danach gefragt hat, sondern weil es besser ist, eine langsame Query unter 50 parallelen Benutzern in Woche 13 zu finden, als sie nach dem Go-Live zu entdecken.
Woche 14 ist Handover und Go-Live Vorbereitung.
Die Handover-Dokumentation, die ich erstelle, deckt ab:
- Infrastructure Übersicht (was wo läuft, wie man es skaliert)
- Database Backup- und Restore-Verfahren, getestet und verifiziert
- Wie man eine neue User Role hinzufügt, ohne Code zu berühren
- Bekannte Limitierungen und die Backlog Items, die wir verschoben haben
Das letzte ist wichtig. Sei ehrlich, was nicht ins Ziel gekommen ist. Kunden respektieren das, und es bereitet die nächste Arbeitsphase sauber vor, statt unausgesprochene Schulden über der Beziehung hängen zu lassen.
Eine letzte Sache zum Go-Live
Staffeln Sie es. Wir haben am Tag 92 für 10 Nutzer soft-launched, 48 Stunden lang die Logs mit Datadog beobachtet und dann für das komplette 80-köpfige Team freigegeben. Dieses 48-Stunden-Fenster hat zwei Edge Cases in den Pipeline-Stage-Übergängen gefunden, die beim Testen nicht aufgetaucht waren. Nichts Katastrophales, aber genau die Art von Problemen, die am ersten Tag 15 Support-Tickets generiert hätten, wenn wir vollgas gegeben hätten.
Go-Live ist nicht das Ende. Es ist nur der Punkt, an dem echte Nutzerverhaltens-Daten ankommen.
---
FAQ
Was kostet ein Custom-CRM wie dieses normalerweise?
Ehrlich gesagt variiert das enorm, aber ein 14-Wochen-Projekt in diesem Umfang mit einem kleinen Team (zwei Back-End-Entwickler, ein Front-End-Entwickler, ein Projektleiter) liegt normalerweise zwischen £60.000 und £120.000, abhängig von der Komplexität der Integrationen und Datenmigration. Wenn Sie Angebote unter £30.000 für ein vollständig custom gebautes System sehen, fragen Sie hart nach, was tatsächlich gebaut wird versus was aus einem bestehenden Template konfiguriert wird.
Kann man ein Custom-CRM auf WordPress bauen?
Man kann, aber ich würde es nicht für mehr als etwa 500 Datensätze oder 20 gleichzeitige Nutzer tun. Die Datenschicht von WordPress ist nicht für relationale CRM-Workloads ausgelegt. Bei Seahawk haben wir für kleinere Kunden Contact-Management-Layer auf WordPress gebaut, aber für etwas Ernsthaftes ist ein ordentliches Back-End mit relationaler Datenbank der richtige Weg.
Was ist der größte Fehler, den Teams beim CRM-Build machen?
Das Berechtigungsmodell zu unterspecifizieren. Alle konzentrieren sich auf Features und vergessen, dass ein CRM mit 80 Nutzern eine differenzierte Antwort auf „wer kann welchen Deal sehen?" braucht, bevor du eine einzige API Route schreibst. Rollenbasierte Zugriffskontrolle in Woche 10 nachzurüsten ist auf eine Weise schmerzhaft, die sich schwer beschreiben lässt, bis du es einmal selbst durchgemacht hast.
Verwendest du immer exakt diesen Tech Stack?
Nein. Der Stack, den ich beschrieben habe, funktionierte für das Team und die Constraints dieses Projekts. Ich habe CRMs auf Laravel und Vue ausgeliefert, auf Django und React, und einmal auf einem Next.js Full-Stack Setup, bei dem ich skeptisch war, das aber tatsächlich gut funktioniert hat. Die Architektur-Prinzipien bleiben gleich. Die Tools sind flexibel.
Am Ende war das Custom-CRM-Projekt nicht nur eine Herausforderung, sondern eine Offenbarung. Dieses enge 14-Wochen-Fenster? Es hat uns gezwungen zu innovieren, anzupassen und zu liefern. Es stellt sich heraus, dass Constraints ein Katalysator für Kreativität sein können. Wer hätte gedacht, dass Deadlines uns so viel über unser Handwerk beibringen könnten? Es sind Projekte wie diese, die mich daran erinnern, warum ich Seahawk Media co-gegründet habe.