Die Make-or-Buy-Frage
„Bauen wir das Portal selbst oder nehmen wir eine fertige Plattform?" — diese Frage steht am Anfang fast jedes Portal-Projekts. Beide Wege haben ihre Berechtigung, beide haben Fallstricke. Wer zu früh entscheidet — oder die Frage ignoriert und die erstbeste Plattform kauft — produziert oft Folgekosten, die das ursprüngliche Budget deutlich übersteigen.
Dieser Artikel ordnet beide Optionen pragmatisch ein und gibt eine Empfehlung, wann welcher Weg sich anbietet.
Beide Wege im Überblick
Eigene Entwicklung
Das Portal entsteht von Grund auf — Architektur, Datenmodell, Frontend und Backend werden für den konkreten Anwendungsfall gebaut. Volle Kontrolle, vollständig anpassbar — aber höherer Anfangsaufwand.
Fertige Plattform
Eine bestehende Lösung (SaaS oder lizenziertes System) wird konfiguriert und ggf. erweitert. Schneller Einstieg, geringerer Anfangsaufwand — dafür Abhängigkeit vom Anbieter und Grenzen bei der Anpassbarkeit.
Wo Plattformen ihre Stärken haben
Fertige Plattformen sind nicht ohne Grund verbreitet — in vielen Szenarien spielen sie ihre Vorteile klar aus:
- Schneller Start. Konfigurieren statt entwickeln — ein einfaches Standard-Portal kann in Tagen statt Monaten produktiv sein.
- Niedriger Anfangsaufwand. Lizenzmodelle verteilen Kosten über Zeit, statt einmalige Entwicklungsbudgets zu binden.
- Erprobte Funktionalität. Was hundertfach im Einsatz ist, hat seine Kinderkrankheiten meist hinter sich. Standardfunktionen funktionieren zuverlässig.
- Pflege durch den Anbieter. Updates, Sicherheitspatches, Performance-Optimierungen laufen im Hintergrund — Sie zahlen dafür, aber müssen sich nicht darum kümmern.
- Wachsendes Ökosystem. Plugins, Erweiterungen, Integrationen — vieles ist bereits verfügbar, ohne dass es entwickelt werden muss.
Wer ein Standard-Bedürfnis hat — einfaches Kundenportal, klassische Wissensplattform, Tickets-System — fährt mit einer Plattform oft besser als mit einer Eigenentwicklung.
Wo Eigenentwicklung überlegen ist
Sobald die Anforderungen aus dem Standard fallen, dreht sich das Bild:
- Volle Anpassbarkeit. Eigene Workflows, eigene Datenstrukturen, eigene Rollenlogik — ohne sich an Plattform-Grenzen zu stoßen.
- Saubere Integration in bestehende Systeme. Statt Plattform-APIs zu nutzen, die nicht passen, entstehen Schnittstellen genau dort, wo sie gebraucht werden.
- Eigentum am Code. Kein Anbieter-Lock-in, keine plötzlichen Preiserhöhungen, keine Abkündigung von Features, auf die Sie sich verlassen haben.
- Langfristig planbare Kosten. Eigene Entwicklung ist initial teurer, läuft aber ohne laufende Lizenzgebühren. Bei langer Nutzungsdauer rechnet sich das.
- Datenhoheit. Personenbezogene Daten, Geschäftsgeheimnisse, sensible Prozesse — auf eigenem Server, ohne Drittanbieter im Datenfluss.
- Wirtschaftlichkeit bei steigenden Anforderungen. Wer eine Plattform stark anpassen muss, zahlt oft mehr als für eine maßgenaue Eigenlösung — und bekommt am Ende ein weniger sauberes Ergebnis.
Worauf es bei der Wahl ankommt
Eine Plattform passt vermutlich, wenn...
- der Anwendungsfall standardnah ist und keine ungewöhnlichen Workflows verlangt.
- die Verfügbarkeit schnell sein muss — Wochen statt Monate bis zum Go-Live.
- das Unternehmen kein dauerhaftes Entwicklungsbudget für das Portal vorsieht.
- die Datenhoheit unkritisch ist (oder die Plattform sie sauber regelt).
- das Portal nicht zentral für das Geschäftsmodell ist.
Eine Eigenentwicklung lohnt sich, wenn...
- das Portal nah am Geschäftsmodell liegt und Wettbewerbsvorteil schafft.
- die Anforderungen deutlich vom Standard abweichen.
- bestehende Systeme tief integriert werden müssen — und Plattform-APIs nicht passen.
- der Datenschutz strenge Anforderungen stellt (eigener Server, eigene Verarbeitung).
- die Nutzungsdauer langfristig ist und laufende Lizenzkosten ungünstig wären.
- Wachstum und Erweiterung mit dem Unternehmen mitgehen sollen, ohne Plattform-Grenzen zu treffen.
In manchen Fällen ist auch ein dritter Weg sinnvoll: Mit einer Plattform starten, um schnell produktiv zu sein, und das Portal später durch eine Eigenentwicklung ablösen, wenn klar ist, was wirklich gebraucht wird. Voraussetzung: Daten und Prozesse müssen so geführt werden, dass eine spätere Migration realistisch bleibt.
Was im Vergleich oft untergeht
Drei Punkte, die in der Make-or-Buy-Diskussion regelmäßig übersehen werden:
- Versteckte Plattform-Kosten. Lizenzgebühren sind nur der Anfang. Plugin-Lizenzen, Storage-Limits, Nutzer-basierte Preismodelle, Premium-Support — die wahren Kosten zeigen sich oft erst nach Monaten.
- Anbieter-Risiko. Plattform-Anbieter können verkauft werden, Geschäftsmodelle ändern, Features streichen. Wer sein Geschäft auf eine fremde Plattform stützt, übernimmt diese Risiken mit.
- Anpassungsfalle. Plattformen versprechen Anpassbarkeit — aber jenseits eines bestimmten Maßes wird das so aufwendig, dass eine Eigenentwicklung günstiger gewesen wäre. Diesen Punkt erkennt man oft erst, wenn man schon investiert hat.
Empfehlung in den meisten Fällen
In meinen Projekten landet die Entscheidung häufig bei einer Eigenentwicklung — nicht aus Prinzip, sondern weil die Anforderungen oft genug zu spezifisch sind, um sauber von einer Plattform abgedeckt zu werden. Wer ein Mittelstandsportal mit eigener Bestelllogik, individuellem Rollenkonzept und Anbindung an mehrere Systeme baut, fährt mit einer maßgenauen Lösung meistens günstiger und sauberer.
Für standardnahe Anwendungsfälle — einfaches Wissensportal, klassisches Ticketsystem, generisches Kundenkonto ohne komplexe Workflows — ist eine fertige Plattform dagegen oft die wirtschaftlichere Wahl.
Was zu Ihrem Vorhaben passt, lässt sich meist in einem ersten Gespräch klären — eine Beschreibung der Rollen, Prozesse und Integrationen reicht für eine erste Einschätzung.