Eine Website hilft Menschen, Ihr Angebot zu verstehen und Kontakt aufzunehmen. Eine Web-App hilft ihnen, eine Aufgabe im Browser zu erledigen. Viele Projekte brauchen beides: öffentlich sichtbare Leistungen und einen geschützten Bereich für laufende Vorgänge.
Das ist eine praktische Unterscheidung für die Planung, keine harte technische Grenze. Eine Website darf einen Rechner, ein Buchungsformular oder einen Chat enthalten. Umgekehrt kann eine Web-App öffentliche Inhalte haben. Die Zahl der Animationen sagt wenig darüber aus, welche Lösung Sie benötigen.
Entscheidend sind die Arbeit, die Ihre Nutzer erledigen sollen, und die Verantwortung für ihre Daten. Die folgenden sieben Fragen helfen, das Projekt vor dem ersten Angebot einzugrenzen.
1. Sollen Menschen sich informieren oder einen Vorgang abschließen?
„Leistungen vergleichen und ein Gespräch anfragen“ spricht zunächst für eine Website. „Ein Dokument einreichen, Rückfragen beantworten und die Freigabe verfolgen“ beschreibt einen Arbeitsablauf.
Schreiben Sie einen Satz aus Nutzersicht: „Als Kunde möchte ich …, damit …“. Wenn danach nur „mehr über uns erfahren“ steht, brauchen Sie keine große Anwendungsarchitektur. Wenn mehrere Zustände und Beteiligte folgen, lohnt sich die genauere Prozessplanung. Die Grenze entsteht durch die Aufgabe, nicht durch die gewünschte Bezeichnung des Produkts.
2. Muss das System sich an einen Vorgang erinnern?
Ein Kontaktformular übermittelt eine Nachricht. Ein Portal speichert beispielsweise, welche Unterlagen fehlen, was bereits geprüft wurde und wer den nächsten Schritt erledigt. Das sind unterschiedliche Anforderungen.
Sobald Menschen später weiterarbeiten müssen, gehören Speicherung, Wiederaufnahme und Änderungshistorie in die Planung. Fragen Sie auch nach Abbrüchen: Was passiert, wenn ein Upload scheitert oder jemand das Fenster schließt? Diese unscheinbaren Situationen entscheiden darüber, ob ein Portal im Alltag hilfreich ist.
3. Sehen alle dieselben Informationen?
Öffentliche Leistungsseiten zeigen grundsätzlich denselben Inhalt. In einer Anwendung kann ein Kunde nur seine Aufträge sehen, eine Sachbearbeiterin mehrere Vorgänge und eine Leitung zusätzliche Auswertungen.
Ein Login allein löst diese Aufgabe nicht. Für jeden Datensatz muss feststehen, wer ihn lesen und verändern darf. Wenn unterschiedliche Rechte nötig sind, kalkulieren Sie ihre Umsetzung und Prüfung von Anfang an. Das gilt auch für Downloads und direkte Links, nicht nur für sichtbare Menüpunkte.
4. Muss etwas mit anderen Systemen synchron bleiben?
Ein Link zu einem vorhandenen Buchungssystem kann genügen. Müssen Termine, Kundendaten oder Bearbeitungsstände dagegen zwischen mehreren Anwendungen übereinstimmen, wird die Integration ein eigener Teil des Projekts.
Erstellen Sie eine kleine Liste: Welches System ist für welche Information maßgeblich? Wer darf Änderungen auslösen? Was passiert bei einem Ausfall? „Wir verbinden das später“ ist riskant, wenn genau diese Verbindung den versprochenen Nutzen ermöglichen soll.
5. Gibt es eine passende Standardlösung?
Wenn Ihr Bedarf bereits gut durch Buchungssoftware, einen Shop oder ein Ticketsystem abgedeckt wird, ist eine eigene Anwendung nicht automatisch die bessere Investition. Prüfen Sie Standardsoftware anhand Ihres Ablaufs einschließlich der Ausnahmen. Ein attraktiver Funktionskatalog allein reicht nicht.
Eine individuelle Web-App wird interessanter, wenn Ihr Prozess deutlich abweicht, mehrere Systeme zusammengeführt werden müssen oder die Bedienung einen wichtigen Unterschied macht. Auch dann kann die beste Lösung aus einer eigenen Oberfläche und vorhandenen Diensten bestehen.
6. Muss das Angebot über Suchmaschinen gefunden werden?
Für öffentliche Leistungen und Fachartikel ist Auffindbarkeit ein eigenes Ziel. Geschützte Kundenakten sollen dagegen nicht in der Suche erscheinen. Trennen Sie diese Bereiche in Inhalt, Navigation und Zugriffsregeln.
Eine Web-App ist nicht grundsätzlich schlecht für SEO. Google kann JavaScript verarbeiten, empfiehlt aber weiterhin serverseitig bereitgestellte oder vorgerenderte Inhalte; nicht jeder Bot führt JavaScript aus. Öffentliche Seiten sollten deshalb ohne Anmeldung erreichbar sein und klare URLs sowie tatsächliche Textinhalte liefern. Quelle: Google zu JavaScript und Suche.
7. Wer betreibt die Lösung nach dem Start?
Eine Anwendung mit laufenden Kundenvorgängen braucht Verantwortliche für Zugänge, Fehler, Datensicherung und Änderungen. Eine redaktionelle Website braucht ebenfalls Pflege, hat aber häufig einen anderen Betriebsumfang.
Benennen Sie eine Person auf Ihrer Seite, die Entscheidungen treffen und Probleme einordnen kann. Fragen Sie im Angebot nicht nur nach der Umsetzung, sondern nach Wartung, Zuständigkeiten, Datenexport und dem Vorgehen bei Störungen. Die monatliche Rechnung erklärt noch nicht, welche Leistungen darin enthalten sind.
Ihre Antworten in einer Entscheidungsmatrix
Die Matrix ist unsere Planungshilfe, kein Punktetest. Ein einziger verbindlicher Kundenprozess kann wichtiger sein als sechs einfache Informationsseiten.
| Ihr Hauptbedarf | Naheliegender Einstieg | Was zusätzlich geprüft werden sollte |
|---|---|---|
| Leistungen erklären und qualifizierte Anfragen gewinnen | Website | Inhalte, Kontaktweg, Ladezeit, Auffindbarkeit |
| Termine nach festen Regeln buchen | Website mit Buchungssystem | Verfügbarkeit, Bestätigung, Stornierung, Datenfluss |
| Dokumente und Bearbeitungsstände je Kunde verwalten | Kundenportal oder passende Standardsoftware | Rechte, Uploads, Status, Wiederherstellung |
| Mehrere interne Werkzeuge in einem Ablauf verbinden | Web-App mit Integrationen | Datenhoheit, Schnittstellen, Fehlerfälle |
| Ein digitales Produkt für viele zahlende Nutzer anbieten | Web-App | Konten, Abrechnung, Support, Betrieb |
| Öffentlich erklären und laufende Aufträge betreuen | Website plus geschützter Anwendungsbereich | Verständlicher Wechsel zwischen beiden Bereichen |
Drei Wünsche, die die Entscheidung häufig verzerren
„Es muss sich wie eine App anfühlen.“ Das kann gute Bedienung meinen oder Installation und Offlinefunktionen. Klären Sie die konkrete Nutzungssituation. Progressive Web Apps können zusätzliche Eigenschaften wie Installation und Offlinebetrieb erhalten; ihre Verfügbarkeit hängt von Umsetzung und Plattform ab. Eine normale Web-App muss nicht installiert werden. Quelle: MDN zu Progressive Web Apps.
„Wir wollen später alles erweitern können.“ Planen Sie erkennbare Anschlussmöglichkeiten, aber bezahlen Sie nicht vorsorglich jede denkbare Zukunft. Halten Sie fest, welche Erweiterung tatsächlich wahrscheinlich ist und woran Sie ihren Bedarf erkennen.
„Der Wettbewerber hat ein Portal.“ Prüfen Sie zuerst, welche wiederkehrende Rückfrage Ihr eigenes Team Zeit kostet. Vielleicht reicht eine verständliche Statusnachricht. Vielleicht fehlt wirklich eine gemeinsame Arbeitsoberfläche. Das lässt sich an echten Vorgängen entscheiden.
Was in ein erstes Briefing gehört
Bei einer geplanten Automatisierung lohnt sich zusätzlich die Frage, wann feste Regeln statt KI genügen. Die Entscheidung für eine Web-App legt das Automatisierungsverfahren noch nicht fest.
Beschreiben Sie die wichtigste Nutzergruppe, eine vollständige Aufgabe, benötigte Informationen und beteiligte Systeme. Ergänzen Sie einen normalen Ablauf und einen typischen Ausnahmefall. Damit können Anbieter vergleichbare Lösungen vorschlagen, statt unterschiedlich große Funktionspakete zu verkaufen.
Für die weitere Planung finden Sie bei uns Web-Anwendungen und individuelle Software. Wenn noch unklar ist, ob eine eigene Anwendung nötig ist, sollte genau diese Entscheidung Teil des ersten Gesprächs sein.