Ich erinnere mich, als wäre es gestern gewesen: der Moment, in dem HubSpot mit den Anforderungen meines Kunden nicht mehr mithalten konnte. Das war 2023, ein florierendes Tech-Startup in Shoreditch. Wir waren mitten in einem HubSpot-Projekt und stellten fest, dass der einzigartige Sales Funnel unseres Kunden ein Quadrat im runden Loch war. Die Tools waren einfach nicht flexibel genug. Sie brauchten etwas Maßgeschneidertes, etwas, das mit ihnen wachsen würde. Also bin ich Kopf über Heels in die Entwicklung eines Custom CRM eingestiegen. Wir nutzten alles von Node.js bis Airtable, jedes Tool maßgeschneidert wie angegossen. Es war eine Augenöffner.
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 SpitzenlastzeitenHubSpot's standard endpoints during peak usage hours
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.its JSON support has matured enormously to the point where you get the flexibility of a document store when you genuinely need it, without abandoning relational integrity.
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. Node.js with Fastify or Python with FastAPI. Fastify specifically is criminally underused for CRM backends. It's faster than Express, the schema validation is built in, and the plugin ecosystem has matured considerably since 2022.
- 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. PostgreSQL 16, with Prisma as the ORM if you're in Node-land, or SQLAlchemy if Python. Don't hand-write SQL for everything. You'll thank yourself in six months.
- 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. Auth0 or Clerk. Building auth yourself in 2026 is a choice I genuinely don't understand. Clerk specifically has become my go-to for anything that needs multi-tenant organisation support out of the box.
- 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. Next.js 14+ with the App Router. The server components shift has genuinely changed how fast internal tools feel to end users.
- 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. Resend for transactional email, Twilio for SMS if needed. Both have proper APIs with sensible rate limits.
- Background Jobs: BullMQ auf Redis. CRMs machen viel asynchrone Arbeit: Syncing, Scoring, Erinnerungen. Du brauchst eine zuverlässige Queue. BullMQ on Redis. CRMs do a lot of async work: syncing, scoring, reminders. You need a reliable 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. If full-text contact/company search is a core feature, add Meilisearch early. It's self-hostable, fast, and far easier to run than 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.Google's Calendar API is well-documented and reliable. The Microsoft Graph API is powerful but has a steeper learning curve. Budget accordingly.
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. when: your sales process is relatively standard, you have fewer than 20 people using the CRM, and you want to be operational within weeks rather than months.
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. when: you have genuinely unique data relationships or workflow logic, you need deep integration with proprietary internal systems, or you've calculated that platform costs over 36 months exceed your build estimate.
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. when: you need the marketing automation and brand-name integrations that come with a platform like HubSpot, but your core CRM logic needs to live somewhere you control. This is more common than people admit. We ran this model for a SaaS client in 2025 where the custom CRM handled all deal logic and contract management, but HubSpot remained the marketing hub. Clean API contract between the two. Worked beautifully.
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.Render or a DigitalOcean managed database cluster keeps your infrastructure costs predictable. I've seen CRMs serving 10,000+ contacts running comfortably on £80 per month in hosting. The variable cost is maintenance and updates, not the server bill.
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, wird es deutlich: Manchmal passen die Standard-Lösungen einfach nicht. Custom-CRM-Entwicklung ist nicht nur ein letzter Ausweg; es ist eine proaktive Entscheidung für diejenigen, die bereit sind, über die Norm hinauszugehen. Während Unternehmen wachsen, müssen ihre Tools auch wachsen. Das richtige CRM kann der Schlüssel sein, um dein Potenzial freizuschalten, aber es sollte sich anfühlen, als wäre es nur für dich gemacht. Und manchmal bedeutet das, die Ärmel hochzukrempeln und von vorne anzufangen.