Marketing-Website, Web-App oder PWA?

Die falsche Frage kommt zuerst

„Sollen wir eine Website oder eine App bauen?“ ist die Frage, die wir in fast jedem Erstgespräch hören. Es ist die falsche Frage. Sie überspringt einen Schritt.

Die richtige Frage lautet: Was muss dieses Produkt tun, und für wen? Eine Marketing-Website, eine individuelle Web-App und eine Progressive Web App (PWA) lösen unterschiedliche Probleme. Die falsche Wahl verschwendet nicht nur Budget – sie legt Sie auf eine Architektur fest, die sich sechs Monate später nur noch teuer wieder auflösen lässt, meist genau dann, wenn die erste Runde echtes Nutzerfeedback eintrifft.

Hier ist das Framework, das wir mit Kunden durchgehen, bevor auch nur eine Zeile Code geschrieben wird – inklusive ehrlicher Kosten- und Zeitrahmen für 2026.

Drei unterschiedliche Aufgaben, keine drei Stufen derselben Aufgabe

Teams behandeln diese drei oft wie eine Leiter – Marketing-Website unten, PWA oben, App dazwischen. Das stimmt nicht. Sie sind keine mehr oder weniger ausgereiften Versionen voneinander. Sie beantworten unterschiedliche Fragen.

Marketing-Website. Aufgabe: einen Besucher in einen Lead oder einen Kauf verwandeln. Content-getrieben, größtenteils öffentlich, keine Nutzerkonten (oder höchstens ein schlankes, nachträglich angeflanschtes für geschützte Inhalte). Erfolg wird an Conversion-Rate, Ladegeschwindigkeit und Suchranking gemessen. Basiert auf einem CMS oder einem Static-Site-Framework, selten mit eigener Backend-Logik jenseits von Formularen und Analytics.

Individuelle Web-App. Aufgabe: einem angemeldeten Nutzer echte Arbeit ermöglichen – Bestände verwalten, Ansprüche prüfen, Termine buchen, Reports erstellen. Hier lebt die Business-Logik: Berechtigungen, Workflows, Datenvalidierung, Integrationen mit CRM oder ERP. Erfolg wird an Bearbeitungszeit und Fehlerquote gemessen, nicht an Page Views.

PWA. Aufgabe: einer Web-App das Gefühl einer nativen App geben – installierbares Icon, Offline-Zugriff auf zentrale Screens, Push-Benachrichtigungen – ohne App-Store-Review-Zyklus und ohne zwei getrennte Codebasen. Sie ist weniger eine vierte Kategorie als vielmehr eine Auslieferungsebene, die auf eine Web-App aufgesetzt wird. Man baut nicht „eine PWA“ anstelle einer Web-App; man baut eine Web-App und entscheidet, wie viel von der PWA-Schicht (Service Worker, Offline-Caching, Install-Prompts) sich zu ergänzen lohnt.

Wie Sie tatsächlich entscheiden

Stellen Sie diese vier Fragen, in dieser Reihenfolge:

1. Meldet sich ein Nutzer an, um wiederkehrende Arbeit zu erledigen, oder liest ein Besucher nur und geht wieder? Wiederkehrende Arbeit → Web-App. Lesen und gehen → Marketing-Website.
2. Muss das Produkt bei instabiler Verbindung funktionieren, auf dem Handy, fernab vom Schreibtisch? Außendiensttechniker, Lagerpersonal, Zusteller – ja. Bürobasierte Wissensarbeiter mit stabiler Verbindung – meist nein, und die PWA-Schicht ist dann Overhead, den Sie noch nicht brauchen.
3. Ist Sichtbarkeit in der Suche ein Weg, wie Menschen Sie finden? Wenn ja, muss dieser Content auf einer schnellen, crawlbaren Marketing-Website liegen – nicht hinter der Login-Wand Ihrer App vergraben –, und er braucht die technischen Grundlagen (die SEO-Basics: serverseitig gerenderter Content, saubere URLs, funktionierendes Schema) von Anfang an – ab dem ersten Commit –, nicht erst nachträglich nach dem Launch angeflanscht.
4. Brauchen Sie beides? Die meisten B2B-Unternehmen schon: eine Marketing-Website, um den Lead zu generieren, und eine Web-App hinter dem Login, in der der zahlende Kunde tatsächlich lebt. Das sind zwei Builds, kein einziger – und sie als ein Projekt zu behandeln, ist einer der häufigsten Gründe, warum Web-Projekte ihr ursprüngliches Budget sprengen.

Wenn Sie die zweite Art bauen – die App, die Ihre Kunden tatsächlich nutzen –, ist das genau der Bereich, in dem unser Team für Webentwicklung die meiste Zeit verbringt, weil sich dort Kosten und Risiko konzentrieren.

Was die Kosten tatsächlich treibt

Kosten hängen nicht in erster Linie von der Seitenzahl oder der Anzahl an Features ab. Es geht um vier Dinge:

Komplexität des Datenmodells. Eine CRUD-App mit einer Handvoll einfacher Entitätstypen ist ein anderer Build als eine mit rollenbasierten Berechtigungen über viele Entitätstypen hinweg samt Audit-Trails. Jede zusätzliche Beziehung vervielfacht die Testfläche, nicht nur das Schema.

Integrationen. Jedes Drittsystem, das Sie anbinden – Stripe, Salesforce, die API eines Versanddienstleisters, eine interne Legacy-Datenbank –, kostet reale Zeit, abhängig davon, wie gut dokumentiert und wie stabil die API dieses Systems ist. Undokumentierte interne Systeme sind eine der größten Quellen für Terminverzug, die wir sehen, weil man die Grenzfälle erst entdeckt, wenn man schon mitten in der Integration steckt.

Echtzeit- und Offline-Anforderungen. Ein Dashboard, das sich beim Laden der Seite aktualisiert, ist günstig. Ein Dashboard mit Live-Updates über WebSockets oder eine mobile Ansicht, die ohne Verbindung funktionieren und später synchronisieren muss, kostet für die betroffenen Screens zusätzliche echte Engineering-Zeit obendrauf.

Reifegrad des Designs. Wer mit einer Figma-Datei startet, in der jeder Zustand (leer, ladend, Fehler, Grenzfall) bereits designt ist, kommt beim Bauen schnell voran. Läuft das Design parallel zur Entwicklung, ist mit Nacharbeit zu rechnen – Screens werden gegen eine Spezifikation gebaut, die sich unter ihnen noch ändert.

Erfahrung und Standort des Teams beeinflussen den Stundensatz, erklären aber selten die größten Ausschläge bei den Gesamtprojektkosten. Das tun die vier oben genannten Faktoren.

Realistische Zeitrahmen für 2026

Das sind grobe Richtwerte für einen einzelnen, gut abgegrenzten Build – nicht für das gesamte Portfolio, das ein großes Unternehmen eventuell braucht –, basierend auf Projekten, die wir kürzlich kalkuliert haben:

• Marketing-Website (eine Handvoll Seiten, CMS-basiert, kein eigenes Backend): einige Wochen.
• Individuelle Web-App, Standardkomplexität (Auth, einige Kern-Entitätstypen, ein bis zwei Integrationen): etwa ein Quartal.
• Individuelle Web-App, hohe Komplexität (mehrstufige Berechtigungen, mehrere Integrationen, Echtzeit-Features): mehrere Quartale oder länger.
• PWA-Schicht ergänzen zu einer bestehenden Web-App (Offline-Caching für zentrale Screens, Install-Prompt, Push): einige Wochen, abhängig davon, wie viel der App offline funktionieren muss statt nur installierbar zu sein.

Wer Ihnen eine feste Zahl nennt, ohne nach Ihrem Datenmodell, Ihren Integrationen und dem Stand Ihres Designs zu fragen, rät nur.

Das Muster, das wir am häufigsten sehen

Der häufigste Fehler ist nicht die falsche Formatwahl – es ist, ein Format zu wählen und es beide Aufgaben erledigen zu lassen. Ein Unternehmen baut eine schicke Marketing-Website und versucht dann, ein Kunden-Dashboard an dieselbe Codebasis anzuflanschen, weil „die ja schon steht“. Monate später kämpfen Dashboard und CMS um die Kontrolle über das Routing, und jedes Content-Update riskiert, eine Funktion im eingeloggten Bereich zu zerschießen.

Die Lösung besteht fast immer darin, beides von Anfang an zu trennen: eine schlanke Marketing-Website, optimiert auf Geschwindigkeit und Suche, und eine separate Web-App, optimiert für den eingeloggten Bereich – mit gemeinsamem Design-System, aber getrennter Codebasis. Das kostet anfangs etwas mehr. Es erspart später einen kompletten Neubau.

Fazit

Fangen Sie nicht mit „Website oder App“ an. Fangen Sie damit an, was der Nutzer eigentlich tut und wie viel davon eine schlechte Verbindung überstehen muss. Behandeln Sie Marketing-Website und eingeloggtes Produkt als zwei getrennte Entscheidungen, selbst wenn ein Team beides baut. Und wenn Sie einen individuellen Build kalkulieren, fragen Sie zuerst nach Datenmodell und Integrationen, erst danach nach der Seitenzahl – dort steckt die eigentliche Zahl.

Wenn Sie kurz davor stehen, einen dieser Builds zu kalkulieren, und eine klare Antwort zu Kosten und Zeitrahmen für Ihren konkreten Fall wollen, sprechen Sie mit uns, bevor Sie die Ausschreibung schreiben.