Drei Begriffe, drei Produktklassen
Schreib „Website mit Kundenlogin“ in eine Ausschreibung, und du bekommst Angebote, die um den Faktor zehn auseinanderliegen — und keines davon ist falsch kalkuliert. Der Grund: Hinter Website, Web-App und Kundenportal stecken drei verschiedene Produktklassen mit eigener Budgetlogik, eigenem Betriebsaufwand und eigenem Erfolgsmaßstab.
Wer die Begriffe im Lastenheft vermischt, vergleicht Angebote, die nicht dasselbe Produkt beschreiben. Und entscheidet am Ende über den Preis statt über die Sache.
Dieser Ratgeber zieht die Grenzen so, wie wir sie in Projekten ziehen: nicht über Technik, denn technisch ist ein Kundenportal eine Web-App — und beide laufen wie eine Website im Browser. Entscheidend sind die drei Kriterien, die Budget und Team tatsächlich bestimmen: Wer nutzt das System? Was soll es ersetzen? Woher kommen die Daten?
Warum die Begriffsfrage eine Budgetfrage ist
Die drei Klassen unterscheiden sich weniger im ersten Angebotspreis als in dem, was danach kommt. Eine Website ist nach dem Launch ein Redaktionsthema: Inhalte pflegen, Suchmaschinen-Sichtbarkeit ausbauen, gelegentlich weiterentwickeln. Eine Web-App ist Software mit Roadmap: Sie lebt von Weiterentwicklung, braucht Betrieb, Monitoring und jemanden, der dafür Verantwortung trägt.
Ein Kundenportal hat zusätzlich eine Integrationsschicht zu ERP oder CRM, die mitgepflegt werden muss, wenn sich die Bestandssysteme ändern. Dazu kommen externe Nutzer, die an Verfügbarkeit und Sicherheit dieselben Erwartungen stellen wie an jede professionelle Software.
Dazu kommt der häufigste Etikettenfehler, den wir in Ausschreibungen sehen: „Portal“ als Sammelbegriff für alles mit Login. Ein Intranet ist kein Kundenportal. Ein internes Auftragstool ist kein Kundenportal.
Das ist keine Wortklauberei: Interne Werkzeuge werden über Prozesskosten gerechtfertigt, Kundenportale über Support-Entlastung und Umsatz — zwei verschiedene Business Cases mit verschiedenen Stakeholdern, Budgettöpfen und Erfolgskriterien.
Drei Definitionen, die vor Fehlkäufen schützen
Website: öffentlich, ohne Login, auf Sichtbarkeit optimiert
Eine Website ist öffentlich. Jeder darf sie sehen, niemand loggt sich ein. Ihr Ziel ist Sichtbarkeit: gefunden werden, Vertrauen aufbauen, Anfragen erzeugen. Die Inhalte kommen aus einem CMS, gepflegt vom Marketing, und der Erfolg wird in Rankings, Anfragen und Conversion gemessen.
Das klingt banal, hat aber eine wichtige Konsequenz: Eine Website ist ein Marketing-Asset, kein Prozesswerkzeug. Formulare, ein Rechner oder ein geschützter Downloadbereich machen daraus noch keine Web-App — entscheidend ist, ob jemand darin arbeitet.
Wenn dein Engpass Sichtbarkeit und Leadgewinnung ist, brauchst du keine Software-Entwicklung, sondern eine gute Website. Das ist die günstigste der drei Antworten, und es ist keine Verlegenheitslösung.
Web-App: geschlossene Nutzergruppe, Prozesse statt Publikum
Eine Web-App hat einen geschlossenen Nutzerkreis, der darin arbeitet — in der Regel deine eigenen Mitarbeiter, manchmal Partner. Login, Rollen und Rechte sind Pflicht, die Daten liegen in einer eigenen Datenbank. Und das Ziel ist ein Prozess: Excel-Listen ablösen, ein Insel-Tool ersetzen, einen Ablauf digital abbilden, den es als Standardsoftware nicht gibt.
Der Erfolg wird nicht in Besuchern gemessen, sondern in Prozesszeit, Fehlerquote und abgelösten Werkzeugen. Ein ehrlicher Zwischenschritt gehört dazu: Bevor du eine Web-App beauftragst, prüfe, ob Standardsoftware den Prozess abdeckt. Individualentwicklung lohnt erst, wenn der Prozess dein Differenzierungsmerkmal ist oder Standardlösungen an deinen Datenflüssen scheitern.
Kundenportal: externe Kunden, Self-Service, ERP-Anbindung
Ein Kundenportal ist technisch eine Web-App — aber die Nutzer sind nicht deine Mitarbeiter, sondern deine externen Bestandskunden. Sie loggen sich ein, um Dinge selbst zu erledigen, für die heute E-Mail und Telefon nötig sind: Auftragsstatus prüfen, Rechnungen abrufen, Tickets stellen, nachbestellen.
Daraus folgt eine andere ROI-Logik: Der Wert entsteht nicht durch schnellere interne Prozesse, sondern durch entlasteten Support und Self-Service als Vertriebskanal. Im B2B heißt das konkret: Firmenkonten, in denen mehrere Personen mit unterschiedlichen Rechten arbeiten, Single Sign-on und sauber getrennte Mandanten.
Und es gibt eine harte technische Konsequenz: Ohne Anbindung an ERP oder CRM bleibt das Portal leer, denn Auftrags- und Rechnungsdaten leben in deinen Bestandssystemen, nicht im Portal. Was ein Portal in jeder Ausbaustufe kostet, zeigt unser Kostenratgeber für Kundenportale.
Die Entscheidungstabelle
Für die Abgrenzung im Alltag reichen sechs Zeilen. Die Kostenspannen sind unsere publizierten Preisanker — keine Marktdurchschnitte und keine „ab“-Lockpreise.
| Kriterium | Website | Web-App | Kundenportal |
|---|---|---|---|
| Nutzerkreis | Öffentlichkeit, anonyme Besucher | Geschlossene Gruppe, meist eigene Mitarbeiter | Externe Bestandskunden, Firmenkonten mit mehreren Nutzern |
| Login | Kein Login (höchstens Formulare, Newsletter) | Pflicht, mit Rollen und Rechten | Pflicht, oft SSO plus Mandantentrennung |
| Primäres Ziel | Sichtbarkeit, Vertrauen, Anfragen | Interne Prozesse abbilden, Insellösungen ablösen | Self-Service: Aufträge, Rechnungen, Tickets ohne E-Mail und Telefon |
| Datenquelle | CMS, gepflegt vom Marketing | Eigene Datenbank, entsteht mit dem System | ERP/CRM — ohne Anbindung bleibt das Portal leer |
| Erfolgsmessung | Rankings, Anfragen, Conversion | Prozesszeit, Fehlerquote, abgelöste Tools | Ticket-Deflection, Nutzungsquote, Umsatz je Kundenkonto |
| Typische Kosten (publizierte happycoding-Anker) | Stark umfangsabhängig — Spannen im Kostenratgeber 2026 (im Text verlinkt) | MVP 8.000–20.000 €, vollständige Webapp 20.000–60.000 € | MVP 8.000–20.000 €, mit Rollen/ERP-Anbindung 20.000–60.000 €, Plattform 60.000–150.000 € |
Stand: Juli 2026. Alle Preise netto. Kostenspannen sind publizierte happycoding-Preisanker, keine Marktdurchschnitte.
Der Praxistest: drei Fragen statt Begriffsdebatte
In Erstgesprächen klären wir die Produktklasse mit drei Fragen — meistens in weniger als zehn Minuten.
Erstens: Wer loggt sich ein? Niemand: Dann ist es eine Website, egal wie umfangreich sie wird. Deine eigenen Mitarbeiter: Dann ist es eine Web-App. Deine Kunden: Dann sprichst du über ein Portal, und ab diesem Punkt gelten Portal-Regeln — Firmenkonten mit mehreren Nutzern, Rollen- und Freigabemodelle, im B2B fast immer SSO.
Zweitens: Was soll das System ersetzen? Eine Broschüre, den Messeauftritt, eine veraltete Selbstdarstellung: Website. Excel-Tabellen, E-Mail-Pingpong zwischen Abteilungen, ein Insel-Tool: Web-App. Die Telefon- und E-Mail-Anfragen deiner Kunden an Vertrieb und Service: Kundenportal. Diese Frage entlarvt die meisten Fehletiketten — ein „Portal“, das nur interne Sachbearbeitung digitalisiert, ist eine Web-App und sollte auch so kalkuliert und gerechtfertigt werden.
Drittens: Woher kommen die Daten? Aus einem CMS, gepflegt vom Marketing: Website. Aus einer eigenen Datenbank, die mit dem System entsteht: Web-App. Aus deinem ERP oder CRM: Kundenportal. Im dritten Fall ist die Integrationsfrage wichtiger als das Frontend — wie Portale per SSO und Schnittstellen an Bestandssysteme andocken, haben wir im Beitrag zur SSO- und ERP-Anbindung von Kundenportalen beschrieben.
Warum die Portal-Frage 2026 drängender ist als die Website-Frage
Die Website-Frage ist meist eine Qualitätsfrage — die Portal-Frage ist inzwischen eine Erwartungsfrage. Schon in einer 2019 via Statista publizierten Microsoft-Umfrage gaben 88 Prozent der Kunden an, von Marken ein Online-Self-Service-Portal zu erwarten.
Im B2B ist die Entwicklung seither deutlicher geworden: Laut Gartner Sales Survey (erhoben August/September 2025, publiziert März 2026) bevorzugen 67 Prozent der B2B-Käufer ein Kauferlebnis ohne Vertriebsmitarbeiter. Eine im Juni 2025 publizierte Gartner-Erhebung lag noch bei 61 Prozent.
Der Sana Commerce B2B Buyer Report 2025 hat deutsche Einkäufer im Sample und wird konkreter: 73 Prozent der B2B-Käufer bevorzugen den Online-Kauf, 75 Prozent erwägen wegen schlechter digitaler Experience den Lieferantenwechsel, und 40 Prozent nennen fehlende Transparenz zu Beständen und Lieferterminen als größte Frustration. Das ist exakt die Information, die ein Portal aus dem ERP heraus beantwortet.
Und Gartner erwartet (August 2025), dass Self-Service und Live-Chat bis 2027 Telefon und E-Mail als meistgenutzte Servicetechnologien überholen.
Ehrlicherweise: Erwartung ist noch kein Business Case. Ob sich ein Portal für deine Kundenstruktur rechnet und wann es schlicht keinen Case gibt, haben wir im Beitrag zum Business Case des Kundenportals durchgerechnet. Wenn du wenige Kunden mit seltenen, individuellen Vorgängen betreust, ist ein Portal die falsche Investition — egal, was Umfragen sagen.
Was der jeweilige Weg kostet — und wohin er führt
Weg 1: Website. Wenn niemand sich einloggt und das Ziel Sichtbarkeit und Anfragen sind, ist eine professionelle Unternehmenswebsite die richtige und zugleich günstigste Antwort. Die Kosten hängen stark von Umfang, CMS und Content-Arbeit ab: Die publizierten Spannen und Preistreiber haben wir im Kostenratgeber für Unternehmenswebsites 2026 aufgeschlüsselt.
Wichtigster Rat: Kauf hier kein Login-Feature „auf Vorrat“ — es verteuert das Projekt und wird später ohnehin als eigene Anwendung neu gebaut.
Weg 2: Web-App. Arbeiten eigene Mitarbeiter im System, bist du bei Individualsoftware — unserer Webapp-Entwicklung. Die publizierten Anker: 8.000 bis 20.000 Euro für einen MVP, 20.000 bis 60.000 Euro für eine vollständige Webapp mit Authentifizierung und Rollen.
Der ROI wird intern gerechnet: Prozessstunden, Fehlerkosten, abgelöste Lizenzen. Genau an dieser Rechnung sollte das Lastenheft hängen, nicht an einer Feature-Liste.
Weg 3: Kundenportal. Loggen sich deine externen Kunden ein und der Kern ist Self-Service mit ERP-Anbindung, bist du beim Kundenportal entwickeln lassen — mit publizierten Ankern: 8.000 bis 20.000 Euro für ein Portal-MVP mit Login und ersten Self-Service-Funktionen, 20.000 bis 60.000 Euro mit Rollen, Firmenkonten und erster ERP-Anbindung, 60.000 bis 150.000 Euro für Portal-Plattformen mit mehreren Mandanten oder Marken.
Unsere Empfehlung ist fast immer der MVP-Einstieg: mit ein bis zwei Self-Service-Funktionen live gehen und den Business Case am echten Nutzerverhalten prüfen, bevor du die große Ausbaustufe beauftragst.
Der Sonderfall: Es existiert schon ein System. Wenn bereits ein Altportal, ein gewachsenes Intranet oder ein Legacy-System da ist, lautet die Frage nicht „Website, Web-App oder Portal?“, sondern „ablösen, ausbauen oder eine moderne Schicht davorsetzen?“ — das ist ein Fall für die Software-Modernisierung.
Der häufigste Teilfall in unserer Praxis: Das Legacy-ERP bleibt unangetastet, und ein neues Portal entsteht als moderne Schicht davor.
Wenn du für die Umsetzung ein Team suchst: Wir bauen solche Projekte als Softwareentwickler aus Berlin, remote für ganz Deutschland.
Der nächste Schritt
Wenn du gerade ein Lastenheft schreibst oder Angebote vergleichst, die nicht vergleichbar wirken: Beantworte die drei Fragen aus dem Praxistest schriftlich (Nutzerkreis, ersetzter Prozess, Datenquelle) und ordne dein Vorhaben einer der drei Klassen zu, bevor du über Preise sprichst.
Wenn du eine zweite Meinung willst: In einem kostenlosen 30-Minuten-Gespräch sagen wir dir, welche Produktklasse dein Vorhaben ist und welche Preisspanne realistisch ist — auch dann, wenn die Antwort lautet: Eine gute Website reicht, spar dir die Software-Entwicklung.
