Ich erinnere mich, als wäre es gestern gewesen: der Moment, in dem HubSpot mit den Anforderungen meines Kunden nicht mehr Schritt halten konnte. Das war 2023, ein lebhaftes Tech-Startup in Shoreditch. Wir waren mitten in einem Projekt mit HubSpot und erkannten, dass der einzigartige Sales Funnel unseres Kunden ein Quadrat in ein rundes Loch passen sollte. Die Tools waren einfach nicht flexibel genug. Sie brauchten etwas Maßgeschneidertes, etwas, das sich mit ihnen weiterentwickeln würde. Also stürzte ich mich kopfüber in die Entwicklung eines individuellen CRM. Wir setzten alles ein, von Node.js bis Airtable, jedes Tool perfekt zugeschnitten. Es war eine Augenöffnung.
Die eigentlichen Zeichen, dass HubSpot seine Grenzen erreicht hat
Die meisten Agency Owner, mit denen ich spreche, erkennen nicht, dass HubSpot das Problem ist. Sie denken, das Problem ist ihr Prozess, ihr Team oder ihre Datenhygiene. Das ist selten der Fall.
Hier sind die Signale, auf die ich achte:
- Dein Sales Team hat ein zweites Spreadsheet gebaut, um Dinge nachzuverfolgen, die HubSpot „technisch" tut, aber schlecht tut
- Du zahlst für einen HubSpot-Plan hauptsächlich, um auf ein oder zwei Features zuzugreifen, die du tatsächlich nutzt
- Deine Entwickler haben mehr als zwei custom-codierte Workflow-Erweiterungen geschrieben
- Reporting erfordert den Export zu Google Sheets, weil HubSpots native Dashboards die Daten nicht zusammenführen können, die du brauchst
- Du erreichst API-Rate-Limits bei HubSpots Standard-Endpoints während der Spitzenlastzeiten
Das letzte wird unterschätzt. Ich hatte einen Kunden in B2B-Logistik, Mitte 2024, der über eine Drittanbieter-Integration 40.000+ Kontakt-Updates pro Tag durchführte. HubSpots API-Limits verursachten Warteschlangen-Verzögerungen, die ihre automatisierte Outreach aus dem Takt brachten. Sie beschuldigten ständig ihr Ops-Team. Es war die Plattform.
Die ehrliche Frage, die du dir stellen solltest: biegst du deine Geschäftslogik zurecht, um das CRM zu passen, oder biegt sich das CRM, um zu dir zu passen? Wenn es das Erste ist, verlierst du bereits an Boden.
Wenn die Mathematik aufgeht
Custom-CRM-Builds sind anfangs teuer. Ich werde dir nichts vormachen. Ein gut definierter Build mit einem soliden Team kostet dich zwischen £25.000 und £120.000, abhängig von Komplexität, Integrationen und ob du zusätzlich eine Mobile-Schicht möchtest.
Aber HubSpots Enterprise-Plan kostet £3.600+ pro Monat. Das sind £43.200 pro Jahr, ohne Add-ons, ohne Ops Hub, ohne irgendwelche Drittanbieter-Connectoren, die du separat zahlst. Über drei Jahre hinweg zahlst du über £130.000 für eine Plattform, die du nicht besitzt und deren Kern du nicht modifizieren kannst.
Die Mathematik verschiebt sich schneller, als die meisten Leute erwarten.
Die richtige Architektur wählen, bevor man eine Zeile Code schreibt
Hier habe ich die teuersten Fehler gesehen. Menschen fangen an zu bauen, ohne die Architektur festzulegen, und verbringen dann sechs Monate mit Umstrukturierung. Seahawk hatte Anfang 2024 ein Fintech-Projekt, bei dem der Client bereits anfing, ein CRM auf einer monolithischen Laravel-Struktur zu bauen, bevor wir involviert waren. Sie hatten Annahmen über Datenbeziehungen getroffen, die drei Schichten tief verankert waren. Die ersten vier Wochen haben wir damit verbracht, das zu entwirren, nicht zu bauen.
Die zwei Architektur-Entscheidungen, die am Anfang am meisten zählen:
Monolith vs. Service-Orientiert
Für die meisten CRM-Builds unter einer bestimmten Skalierung (sagen wir, weniger als 500 gleichzeitige interne Nutzer) ist ein gut strukturierter Monolith immer noch vollkommen ausreichend. Rails, Laravel, Django. Sie sind langweilig, aber auf die beste Art. Man kann schnell vorankommen, und man endet nicht damit, Inter-Service-Kommunikation zu debuggen, wenn man eigentlich Features ausliefern sollte.
Service-orientierte Architektur ist sinnvoll, wenn man wirklich unterschiedliche Domänen hat, die unabhängig voneinander skaliert werden müssen. Zum Beispiel, wenn dein CRM auch ein kundenorientiertes Portal mit Echtzeit-Daten antreibt, dazu noch eine separate Analytics-Engine und eine Mobile App. In diesem Fall lohnt sich die Aufteilung der Verantwortlichkeiten.
Lass dich nicht von jemandem Microservices verkaufen, weil es modern klingt. Ich habe zu viele £60k-Projekte gesehen, die ein £25k-Monolith hätten sein sollen.
Relational vs. Document Store
Die meisten CRM-Daten sind von Natur aus relational. Kontakte haben Unternehmen. Unternehmen haben Deals. Deals haben Aktivitäten. PostgreSQL handhabt das außergewöhnlich gut, und seine JSON-Unterstützung hat sich so sehr weiterentwickelt, dass man die Flexibilität eines Document Stores bekommt, wenn man sie wirklich braucht, ohne relationale Integrität aufzugeben.
MongoDB ist sinnvoll, wenn deine Kontaktdatensätze in ihrer Struktur über deine Nutzerbasis hinweg wildly inkonsistent sind. Das ist ein echtes Szenario für einige Unternehmen. Für die meisten ist es das nicht.
Meine Standard-Wahl für 2026: PostgreSQL, jedes Mal, bis zum Beweis des Gegenteils.
Der Tech Stack, den ich 2026 tatsächlich empfehlen würde
Keine theoretischen Antworten hier. Das ist, was ich jetzt bauen würde.
- Backend: Node.js mit Fastify oder Python mit FastAPI. Fastify speziell wird für CRM-Backends kriminell unternutzt. Es ist schneller als Express, die Schema-Validierung ist eingebaut, und das Plugin-Ökosystem hat sich seit 2022 erheblich weiterentwickelt.
- Database: PostgreSQL 16, mit Prisma als ORM wenn du im Node-Land bist, oder SQLAlchemy wenn Python. Schreib nicht überall SQL von Hand. Du wirst dir selbst in sechs Monaten dankbar sein.
- Auth: Auth0 oder Clerk. Auth selbst zu bauen 2026 ist eine Entscheidung, die ich ehrlich nicht verstehe. Clerk speziell ist mein Go-to für alles geworden, das Out-of-the-Box Multi-Tenant-Organisation-Support braucht.
- Frontend: Next.js 14+ mit dem App Router. Der Server-Components-Shift hat wirklich verändert, wie schnell interne Tools sich für Endnutzer anfühlen.
- Email/Comms-Schicht: Resend für transaktionale E-Mails, Twilio für SMS wenn nötig. Beide haben ordentliche APIs mit vernünftigen Rate Limits.
- Background Jobs: BullMQ auf Redis. CRMs machen viel asynchrone Arbeit: Syncing, Scoring, Erinnerungen. Du brauchst eine zuverlässige Queue.
- Search: Wenn Volltext-Kontakt-/Unternehmenssuche ein Kern-Feature ist, füg Meilisearch früh hinzu. Es ist selbst-hostbar, schnell, und weitaus einfacher zu betreiben als Elasticsearch.
Das ist ein kompletter Stack für 85 % der Custom-CRM-Projekte, denen ich begegne. Die restlichen 15 % haben Mobile- oder Real-Time-Anforderungen, die React Native oder WebSockets ins Spiel bringen.
Datenmigration: Der Teil, den jeder unterschätzt
Ehrlich gesagt, bei der Datenmigration gehen Projekte leise in die Brüche. Nicht beim Build. Bei der Migration.
Wenn du von HubSpot wechselst, erwarte, dass der Export unordentlicher ist als gedacht. HubSpots Datenmodell hat viele implizite Assoziationen. Assoziationen zwischen Kontakten und Unternehmen sind in der Export-CSV nicht immer sauber. Custom Properties kommen mit internen Feldnamen heraus, die nicht den Anzeigenamen entsprechen. Deal-Phasen werden über numerische IDs referenziert, die du manuell abgleichen musst.
Ich würde mindestens vier Wochen dedizierter Migrationsarbeit für eine mittlere HubSpot-Instanz einplanen (sagen wir 50.000 Kontakte, 10.000 Deals). Das umfasst:
- Audit und Mapping aller Custom Properties
- Transformation Scripts schreiben (Python ist dafür hervorragend, speziell pandas für die unordentlichen Zwischenschritte)
- Mindestens zwei Wochen mit parallelen Systemen laufen lassen, bevor der Wechsel erfolgt
- Einen Rollback planen. Immer einen Rollback planen.
Wenn du parallel Running auslässt, wirst du es bereuen. Ein Kunde von mir hat einen Hard Cutover freitagsnachmittags gemacht. Am Montag hatten sie drei Datenintegritätsprobleme gefunden, deren Behebung zwei Wochen dauerte. Auf einem Live-Produktionssystem. Sei nicht diese Person.
Integrationen, die in einem Custom Build wirklich zählen
Das CRM existiert nicht isoliert. Du wirst es immer mit etwas verbinden müssen. Hier verbringe ich die meiste Zeit bei Integrationen:
Finanzen und Abrechnung
QuickBooks oder Xero für die meisten UK-basierten Kunden. Beide haben solide APIs. Das Wichtigste ist, die Richtung der Wahrheit richtig zu setzen: Ist das CRM die Quelle der Wahrheit für Deal-Werte, oder ist es das Buchhaltungssystem? Entscheide dich für eines. Eine bidirektionale Synchronisation ohne klare Autorität führt zu Konflikten, die um 23 Uhr wirklich schmerzhaft zu debuggen sind.
Kalender und Kommunikation
Google Workspace und Microsoft 365 sind das Minimum. Googles Calendar API ist gut dokumentiert und zuverlässig. Die Microsoft Graph API ist leistungsstark, hat aber eine steilere Lernkurve. Plane dementsprechend.
Marketing Automation
Hier möchten die Leute oft einen Teil von HubSpot behalten, speziell die Marketing-Seite, während sie das Sales-CRM ersetzen. Das ist ein völlig valider Hybrid-Ansatz. Nutze HubSpots API, um Kontaktupdates und Deal-Stage-Änderungen zurück an Marketing-Listen zu übertragen. Das funktioniert gut, wenn der Datenvertrag klar definiert ist.
Build vs. Buy vs. Hybrid: Die Entscheidung treffen
Das wird mir ständig gestellt. Und es gibt keine universelle Antwort, aber es gibt ein Framework, das ich nutze.
Kaufen (HubSpot, Salesforce, Pipedrive), wenn: Ihr Vertriebsprozess relativ standardisiert ist, weniger als 20 Personen das CRM nutzen und Sie innerhalb von Wochen statt Monaten betriebsbereit sein möchten.
Custom bauen, wenn: Sie wirklich einzigartige Datenbeziehungen oder Workflow-Logik haben, Sie tiefe Integration mit proprietären internen Systemen benötigen oder Sie berechnet haben, dass Plattformkosten über 36 Monate Ihre Build-Schätzung übersteigen.
Hybrid, wenn: Sie die Marketing-Automation und etablierten Integrationen einer Plattform wie HubSpot benötigen, aber Ihre Core-CRM-Logik an einem Ort leben soll, den Sie kontrollieren. Das ist häufiger, als Menschen zugeben. Wir haben dieses Modell 2025 für einen SaaS-Kunden implementiert, bei dem das Custom-CRM die gesamte Deal-Logik und Vertragsverwaltung übernahm, während HubSpot das Marketing-Hub blieb. Sauberer API-Vertrag zwischen den beiden. Hat wunderbar funktioniert.
Das schlechteste Szenario ist neun Monate damit zu verbringen, ein Custom-CRM zu bauen, das genau das macht, was HubSpot tut, aber schlechter. Das passiert. Normalerweise dann, wenn die Entscheidung zum Custom-Build emotional statt analytisch getroffen wurde.
FAQ
Wie lange dauert ein Custom-CRM-Build wirklich?
Realistische Zeitrahmen: Ein schlankes MVP mit Core-Kontaktverwaltung, Deal-Tracking und grundlegendem Reporting dauert etwa 10 bis 14 Wochen mit einem Team aus zwei bis drei Personen. Vollständig ausgestattete Builds mit mehreren Integrationen, Custom Reporting und einer Mobile-Ebene erstrecken sich auf sechs bis neun Monate. Jeder, der Ihnen vier Wochen für etwas Komplexes anbietet, plant entweder Abstriche zu machen oder hat das Projekt nicht richtig gescoped.
Kann ich ein Custom-CRM selbst hosten und die Kosten niedrig halten?
Ja, und für viele Kunden ist das die richtige Entscheidung. Ein gut konfiguriertes Setup auf etwas wie Render oder einem DigitalOcean Managed-Database-Cluster hält Ihre Infrastrukturkosten vorhersehbar. Ich habe CRMs gesehen, die 10.000+ Kontakte verwalten und komfortabel mit £80 pro Monat für Hosting laufen. Die variable Kosten sind Wartung und Updates, nicht die Serverrechnung.
Welcher Fehler ist der größte, den Teams beim Bauen eines Custom-CRM machen?
Für die Zukunft bauen, die sie sich vorstellen, nicht für die Gegenwart, die sie haben. Ich habe Teams gesehen, die KI-gesteuerte Lead-Bewertung, prädiktive Pipeline-Prognosen und eine vollständige Mobile App spezifizieren, bevor sie nicht mal die grundlegende Deduplizierung hinbekommen haben. Macht zuerst die langweiligen Sachen richtig. Deduplizierung, Datenvalidierung, Audit-Logs, Benutzerberechtigungen. Diese Dinge sind unsexy und absolut kritisch. Alles andere ist optional, bis diese solide sind.
Ist die Migration weg von HubSpot wirklich so schwierig?
Schwieriger als ihre Dokumentation vermuten lässt, einfacher als Salesforce. Die größte Reibung entsteht bei benutzerdefinierten Properties, Workflow-Logik und E-Mail-Sequenzverlauf. Die Kontakt- und Deal-Daten selbst exportieren relativ sauber. Rechne mit Überraschungen in der Workflow-Logik. HubSpot-Workflows kodieren oft Geschäftsregeln, die nirgendwo anders dokumentiert wurden, und du wirst sie erst entdecken, wenn du bereits halb durch die Migration bist.
Wenn ich auf das Shoreditch-Projekt zurückblicke, ist eines klar: Manchmal erfüllen vorgefertigte Lösungen einfach nicht die Anforderungen. Benutzerdefinierte CRM-Entwicklung ist nicht nur ein letzter Ausweg; sie ist eine proaktive Wahl für diejenigen, die bereit sind, über die Norm hinauszugehen. Mit dem Wachstum von Unternehmen müssen auch ihre Tools wachsen. Das richtige CRM kann der Schlüssel sein, um dein Potenzial freizusetzen, aber es sollte sich anfühlen, als wäre es nur für dich gemacht worden. Und manchmal bedeutet das, die Ärmel hochzukrempeln und von vorne zu beginnen.
Weiterführende Lektüre: AI-Suchschlüsselwort-Recherche 2026: was es ist, warum traditionell, Technical SEO und AI-Suche.