Web-App entwickeln lassen: Bausteine, Ablauf und Kostenfaktoren

Eine Web-App ist ein Programm, das im Browser läuft: Nutzer melden sich an, arbeiten mit ihren eigenen Daten, und das System merkt sich, was sie tun. Eine Web-App entwickeln zu lassen lohnt sich, wenn Ihre Abläufe nicht in Standardsoftware passen oder Sie Ihren Kunden ein eigenes Portal bieten wollen. Hier lesen Sie, woraus eine Web-App besteht, wie ein Projekt abläuft, was den Aufwand bestimmt und welche Fragen Sie einem Entwickler stellen sollten.

Web-App vs. Webseite: der eigentliche Unterschied

Eine Webseite informiert. Alle Besucher sehen dieselben Inhalte, und am Ende steht meist ein Anruf oder eine Anfrage. Eine Web-App dagegen erledigt etwas: Jede Person sieht nach dem Login ihre eigenen Daten, legt etwas an, ändert es, gibt es frei.

Merkmal	Webseite	Web-App
Zweck	informieren, Anfragen gewinnen	Aufgaben erledigen
Inhalte	für alle gleich	je nach Person und Rolle verschieden
Login	meist keiner	Kern der Anwendung
Daten	Texte und Bilder	Datensätze, die Nutzer selbst anlegen
Logik	wenig, etwa ein Formular	Regeln, Berechnungen, Benachrichtigungen

Die Grenze ist fließend. Ein Kontaktformular macht aus einer Webseite noch keine App. Ein Buchungssystem mit Kundenkonto, Stornofristen und Erinnerungsmails schon. Typische Web-Apps im Geschäftsalltag sind:

• ein Kundenportal, in dem Kunden Aufträge, Dokumente oder Rechnungen einsehen
• ein Buchungs- oder Reservierungssystem mit eigenen Regeln
• eine interne Verwaltung für Aufträge, Einsätze oder Lagerbestand
• ein Rechner, der Angebote kalkuliert und speichert
• eine Plattform, die selbst das Geschäftsmodell ist

Brauchen Sie eigentlich eine gute Webseite mit ein, zwei Funktionen, ist das ein anderes Projekt. Dazu mehr auf unserer Seite zu Webdesign und Entwicklung.

Wann sich eine eigene Web-App lohnt – und wann nicht

Bevor Sie eine Web-App entwickeln lassen, lohnt der ehrliche Blick auf die Alternativen. Es gibt grob drei Wege.

Standardsoftware passt, wenn Ihr Ablauf branchenüblich ist: Buchhaltung, Newsletter, ein gängiges Terminsystem. Sie zahlen eine laufende Gebühr und bekommen Updates und Support. Dafür richten Sie sich nach der Software, nicht umgekehrt.

No-Code-Werkzeuge setzen Datenbanken, Formulare und Automatisierungen per Mausklick zusammen. Für interne Listen, kleine Teams und erste Prototypen ist das oft genug. Schwierig wird es meist bei fein abgestuften Rechten, beim Zugang für externe Kunden, bei Kosten, die mit jedem Nutzer steigen, und bei der Frage, auf welchen Servern die Daten liegen.

Eine individuelle Web-App ist die passende Wahl, wenn mindestens einer dieser Punkte zutrifft:

• Ihr Ablauf ist ein Grund, warum Kunden zu Ihnen kommen, und soll nicht in ein fremdes Schema gepresst werden.
• Sie übertragen Daten regelmäßig von Hand zwischen mehreren Programmen.
• Kunden oder Partner sollen selbst etwas einsehen oder erledigen können.
• Sie wollen Daten, Code und Weiterentwicklung in der eigenen Hand haben.

Trifft nichts davon zu, ist fertige Software meist die bessere Wahl. Ein guter Entwickler sagt Ihnen das auch.

Die Bausteine einer Web-App

Von außen sieht eine Web-App aus wie eine Webseite. Dahinter arbeiten mehrere Teile zusammen.

Was bei einem Klick in einer Web-App passiert

1. 1OberflächeDie Nutzerin klickt im Browser auf „Auftrag freigeben“.
2. 2Login und RollenDer Server prüft: Wer ist das, und darf diese Person freigeben?
3. 3Backend und APIDie Logik prüft die Eingaben, ändert den Status, verschickt eine Benachrichtigung.
4. 4DatenbankDer neue Stand wird dauerhaft gespeichert und ist für alle Berechtigten sichtbar.

Schnittstellen: Über das Backend kann die App mit anderen Systemen sprechen, etwa Zahlungsanbieter, E-Mail-Versand, Kalender oder Buchhaltung.

Oberfläche (Frontend)

Das, was Nutzer sehen und bedienen: Listen, Formulare, Filter, Dashboards. Eine gute Oberfläche funktioniert am Handy genauso wie am großen Bildschirm und bleibt mit Tastatur und Screenreader bedienbar. Öffentliche Teile, etwa eine Buchungsmaske, sollten so schnell laden wie eine gute Webseite. Einen Maßstab dafür liefern die Core Web Vitals.

Backend und API

Das Backend läuft auf dem Server und enthält die Regeln: Wer darf was, welche Fristen gelten, was passiert nach einer Buchung? Die API ist die Schnittstelle, über die Oberfläche und Server miteinander reden. Gut gebaut, können später auch andere Programme oder eine Handy-App dieselbe API nutzen.

Datenbank

Hier liegen Kunden, Aufträge, Termine und deren Beziehungen zueinander. Das Datenmodell ist eine der wichtigsten Entscheidungen im ganzen Projekt. Ein sauberes Modell lässt sich Jahre später noch erweitern, ein schlampiges bremst jede neue Funktion.

Login und Rollen

Anmeldung per Passwort oder per Link in der E-Mail, dazu Rollen wie Kunde, Mitarbeiter und Administrator. Je feiner die Rechte abgestuft sind, desto genauer muss man sie vorher beschreiben.

Admin-Bereich

Ein Verwaltungsbereich, in dem Ihr Team Nutzer anlegt, Einstellungen ändert und Inhalte pflegt. Er wird oft vergessen und ist im Alltag doch der Teil, den Ihre Mitarbeiter am meisten benutzen.

Schnittstellen zu anderen Systemen

Zahlungen, Mailversand, Kalender, Buchhaltung oder Ihre bestehende Software: Anbinden lässt sich vieles, sofern das andere System eine dokumentierte Schnittstelle oder zumindest einen Datenexport bietet. Das sollte vor der Zusage geprüft werden, nicht danach.

Ablauf: vom ersten Gespräch zum laufenden Betrieb

1. Anforderungen klären

Am Anfang steht keine Funktionsliste, sondern die Frage, wer was erledigen will. Hilfreich sind kurze Sätze nach dem Muster „Als Kundin möchte ich meine offenen Rechnungen sehen, damit ich nicht nachfragen muss“. Dazu gehören die Sonderfälle: Was passiert bei einer Stornierung, einem Doppeleintrag, einem vergessenen Passwort?

2. Klickbarer Entwurf

Bevor programmiert wird, entsteht ein Entwurf, durch den man sich klicken kann. Hier fallen Missverständnisse auf, solange sie noch billig zu beheben sind. Zeigen Sie den Entwurf den Menschen, die die App später wirklich benutzen.

3. Erster lauffähiger Stand (MVP)

Der erste echte Stand enthält nur die wichtigsten Abläufe, die aber vollständig: mit Login, echten Daten und sauberer Speicherung. MVP steht für „Minimum Viable Product“, also das kleinste Produkt, das im Alltag schon nützt. Sie testen es mit echten Nutzern und merken, was fehlt oder stört.

4. Schrittweise ausbauen

Danach wächst die App in kleinen Etappen. Jede Etappe wird getestet und ausgeliefert, bevor die nächste beginnt. So bleibt die Richtung korrigierbar, und Sie zahlen nicht für Funktionen, die am Ende niemand braucht.

5. Betrieb

Eine Web-App ist nach dem Start nicht fertig. Sie braucht Hosting, regelmäßige Backups, Sicherheitsupdates für Server und verwendete Bibliotheken und jemanden, der reagiert, wenn etwas ausfällt. Klären Sie früh, wer das übernimmt.

Was den Aufwand bestimmt

Preisspannen nennen wir bewusst nicht: Zwei Web-Apps mit ähnlichem Namen können sich im Aufwand stark unterscheiden. Diese Faktoren entscheiden:

• Rollen und Abläufe: Jede Rolle mit eigenen Rechten und jeder Ablauf mit eigenen Regeln will gebaut und getestet werden.
• Sonderfälle: Ausnahmen, Fristen und Freigabeschritte machen oft mehr Arbeit als der Normalfall.
• Schnittstellen: Wie viele Systeme sind anzubinden, und wie gut sind deren Schnittstellen dokumentiert?
• Datenübernahme: Bestehende Excel-Listen oder Altdaten müssen bereinigt und übertragen werden.
• Oberfläche: eigenes Design oder bewährte Bausteine, eine Sprache oder mehrere.
• Anforderungen an Sicherheit und Verfügbarkeit: Gesundheits- oder Finanzdaten brauchen mehr Sorgfalt als eine interne Urlaubsliste.
• Betrieb: Hosting, Wartung und Weiterentwicklung fallen laufend an.

Viele Überlegungen aus unserem Artikel Was kostet eine Webseite? gelten auch hier, besonders die zu Folgekosten und vergleichbaren Angeboten.

Web-App oder native App?

Eine native App wird für iOS oder Android gebaut und über den App Store verteilt. Eine Web-App läuft in jedem modernen Browser, mit einer gemeinsamen Codebasis für alle Geräte. Updates sind sofort bei allen Nutzern, ohne Freigabe durch einen Store.

Als Progressive Web App (PWA) lässt sich eine Web-App außerdem auf den Startbildschirm legen und startet dann im eigenen Fenster. Mit einem Service Worker kann sie Inhalte zwischenspeichern und teilweise offline funktionieren (MDN: Progressive Web Apps).

Eine native App lohnt sich vor allem, wenn Ihre Nutzer die Anwendung im App Store suchen oder wenn Sie Gerätefunktionen brauchen, die im Browser nicht oder nur eingeschränkt verfügbar sind. Wie viel ein Browser kann, unterscheidet sich je nach Betriebssystem. Prüfen Sie das für Ihre konkreten Funktionen, bevor Sie sich festlegen.

Sicherheit und DSGVO: die Grundsätze

Sobald personenbezogene Daten verarbeitet werden, gilt die DSGVO. Das ersetzt keine Rechtsberatung, aber einige Grundsätze sollte jede Web-App erfüllen:

• Passwörter sicher speichern: nie im Klartext, sondern mit einem Hash-Verfahren, das für Passwörter gedacht ist, etwa Argon2 oder bcrypt. Dann kann sie auch niemand im Team auslesen.
• Rechte auf dem Server prüfen: Einen Knopf in der Oberfläche auszublenden reicht nicht. Fehlerhafte Zugriffskontrolle gehört zu den Risiken, die die OWASP Top Ten aufführen.
• Verschlüsselte Verbindungen: durchgehend HTTPS, auch im Admin-Bereich.
• Datensparsamkeit: nur speichern, was für den Zweck wirklich nötig ist (Art. 5 DSGVO), und Datenschutz von Anfang an einplanen (Art. 25 DSGVO). Dazu gehört auch, festzulegen, wann Daten wieder gelöscht werden.
• Serverstandort: Auf Wunsch laufen Server und Datenbank in der EU. Verarbeitet ein Dienstleister Daten in Ihrem Auftrag, brauchen Sie einen Auftragsverarbeitungsvertrag (Art. 28 DSGVO).
• Backups und Updates: regelmäßig, automatisch und mit getesteter Wiederherstellung.

Worauf Sie bei der Auswahl eines Entwicklers achten sollten

Referenzen und Technik-Begriffe sagen wenig darüber, wie ein Projekt im Alltag läuft. Aussagekräftiger sind die Antworten auf diese Fragen:

• Wie klären Sie Anforderungen, bevor Sie programmieren?
• Wann sehe ich den ersten klickbaren Entwurf und wann den ersten lauffähigen Stand?
• Mit welcher Technik arbeiten Sie, und ist sie verbreitet genug, dass auch andere später weiterarbeiten können?
• Wem gehören Code, Daten und Zugänge nach dem Projekt?
• Wo werden die Daten gespeichert, und gibt es einen Auftragsverarbeitungsvertrag?
• Wie wird getestet, und wie gehen Sie mit Sicherheitsupdates um?
• Wer betreut die App nach dem Start, und wie schnell reagieren Sie bei einem Ausfall?
• Wie werden Änderungswünsche während des Projekts behandelt und abgerechnet?

Wer auf diese Fragen klar und ohne Ausweichen antwortet, plant meist auch das Projekt sauber.

Checkliste für Ihr Briefing

1. Welches Problem soll die App lösen, und wie wird es heute erledigt?
2. Wer nutzt sie: Kunden, Mitarbeiter, Partner? Mit welchen Rechten?
3. Die drei bis fünf wichtigsten Abläufe, in einfachen Sätzen beschrieben
4. bekannte Sonderfälle und Ausnahmen
5. Systeme, die angebunden werden sollen
6. vorhandene Daten, die übernommen werden müssen
7. Geräte: vor allem Handy, vor allem Rechner oder beides?
8. Anforderungen an Datenschutz und Serverstandort
9. Was gehört in den ersten Stand, was kann warten?
10. Zeitrahmen und grober Budgetrahmen
11. Wer kümmert sich nach dem Start um Betrieb und Weiterentwicklung?

Wir bauen solche Web-Apps vollständig, von der Oberfläche über Backend und Datenbank bis zum Login, und betreuen sie auf Wunsch auch im Betrieb. Wie das bei uns abläuft, steht auf unserer Seite zur Web-App-Entwicklung. Oder beschreiben Sie uns über das Kontaktformular kurz, was Ihre App können soll und wer sie nutzt.