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)
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 (ein mittelgroßes Logistikunternehmen in Birmingham mit etwa 80 Mitarbeitern) verbrachte ich die ersten zwei Wochen damit, fast nur zuzuhören. Workshops, aufgezeichnete Zoom-Calls und 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 okay, Widersprüche in einem Discovery-Dokument sind kostenlos; Widersprüche, die man in Woche 11 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 kartografieren, die jede architektonische Entscheidung danach prägen werden. Ich nutze Whimsical für Flussdiagramme in dieser Phase. Schnell, teilbar, und Clients können kommentieren, ohne ein Konto zu brauchen.data relationships and the user roles that will shape every architectural decision downstream. I use Whimsical for flow diagrams at this stage. Quick, shareable, and clients can comment without needing an account.
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.Node.js with Express on the backend, PostgreSQL for the database, React on the front end, and the whole thing deployed on DigitalOcean managed Kubernetes. We used Prisma as the ORM because the schema was going to evolve quickly and Prisma's migration workflow is genuinely good for that.
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.Auth0 unless there's a compelling reason not to. It handles the edge cases (password resets, MFA, social login) that eat junior developers alive.
---
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.Postman before writing a controller, which sounds tedious but saves about two weeks of "wait, what does this endpoint return?" conversations later.
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.custom_field_definitions table properly from day one is about four hours of work. Improvising it in week 11 is a nightmare.
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.TanStack Query for server state management. I tried rolling with plain useEffect and local state on a smaller project in 2022. Never doing that to myself again, TanStack Query handles caching, background refetching, and optimistic updates in a way that makes CRM interfaces feel snappy without heroics.
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.shadcn/ui on this project. It's not a component library in the traditional sense; you own the code, which means you can actually customise it without fighting the library. For a CRM with a pipeline view, a contacts table, and a task board, that flexibility matters.
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.empty states. A CRM with no data looks broken if you haven't designed for zero-state screens. Build them early. Clients demo to stakeholders with empty databases and first impressions stick.
---
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.Xero accounting setup and an older Salesforce instance they were migrating away from. Two weeks sounds tight. It was, but we made it because we'd stubbed the integration points back in Phase 3.
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.Bulk API 2.0 to extract the data, then ran it through a Node script that mapped their field structure to ours. The script took a day to write and three days to iterate on because Salesforce data is almost never as clean as clients believe it is. Budget for data cleaning. Always.
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.Xero developer docs are actually decent, for what it's worth. The OAuth 2.0 flow is well documented and their sandbox environment works reliably.
---
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.ClickUp board with every test case written as a task, they test, they mark it, they attach a Loom if something breaks. This gets real users clicking real flows, which always uncovers things that a developer-run test misses. Someone will try to paste 4,000 characters into a "notes" field. Someone will import a CSV with smart quotes in it. You want to find this now.
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.Lighthouse against every key page. I also run k6 load tests against the API, not because the client asked for it, but because finding a slow query under 50 concurrent users in week 13 beats finding it after go-live.
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.Datadog, then opened it to the full 80-person team. That 48-hour window caught two edge cases in the pipeline stage transitions that hadn't shown up in testing. Nothing catastrophic, but the kind of thing that would have generated 15 support tickets on day one if we'd gone full-steam.
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.