WebApp entwickeln lassen — Ablauf, Zeitrahmen, Fallstricke.

Jede WebApp beginnt mit einer Liste, die zu lang ist. Der erste Arbeitsschritt ist nicht Design, sondern Streichen: Welcher einzige Ablauf entscheidet darüber, ob das Produkt funktioniert? Genau der wird gebaut, alles andere wird verbindlich als Nicht-Ziel festgeschrieben.

• Ein Kern-Flow: anmelden, etwas anlegen, Ergebnis sehen. Wenn dieser Weg nicht überzeugt, hilft kein zweites Feature.
• Eine Nutzerrolle mehr als nötig ist teuer: jede zusätzliche Rolle verdoppelt die Zustände, die getestet werden müssen.
• Reporting kommt später: Auswertungen sind erst sinnvoll, wenn Daten entstehen. Vorher sind sie Vermutungen in Diagrammform.

Ein sauber geschnittener erster Umfang ist kein Qualitätsverzicht, sondern die Voraussetzung dafür, überhaupt zu lernen, bevor das Budget aufgebraucht ist.

Bildschirme lassen sich jederzeit ändern, Datenstrukturen kaum. Deshalb wird zuerst festgelegt, welche Objekte es gibt, wie sie zusammenhängen und wer welche Zeile sehen darf.

• Rechte in der Datenbank, nicht im Frontend: Zugriffsregeln gehören auf Zeilenebene in die Datenbank (Row-Level-Security). Eine Prüfung nur im Interface ist keine Zugriffskontrolle.
• Migrations von Tag 1: jede Schemaänderung als versionierte Datei. Ohne das ist ein zweiter Entwickler später kaum einsetzbar.
• Löschkonzept früh: Was passiert, wenn ein Nutzer sein Konto löscht? Diese Frage nachträglich zu beantworten bedeutet, das Modell erneut anzufassen.

So sieht ein realistischer Ablauf für eine erste tragfähige Version aus. Die Dauer hängt weniger an der Entwicklungsgeschwindigkeit als an der Geschwindigkeit deiner Entscheidungen.

1. Woche 1 — Scope-Session: Flows, Datenmodell, Rollen, Nicht-Ziele. Ergebnis ist ein Dokument, gegen das später gemessen wird.
2. Woche 2 — Fundament: Repository, Deployment, Anmeldung, Datenbank mit Rechtemodell, EU-Hosting. Ab hier ist jeder Stand öffentlich sichtbar.
3. Woche 3–5 — Kern-Flow: der Weg, an dem das Geschäftsmodell hängt, inklusive Fehlerzustände und Leerzuständen.
4. Woche 6 — Härtung & Go-Live: Fehler-Monitoring, Protokolle, Datenschutzdokumente, Test mit echten Nutzern.
5. Ab Woche 7 — Iteration: zweiwöchige Zyklen nach Nutzungsdaten, nicht nach Wunschliste.

Wird die erste Version größer geplant, verschiebt sich nicht nur der Termin — es verschiebt sich der Zeitpunkt, an dem du das erste Mal echtes Feedback bekommst.

Externe Umsetzung ersetzt nicht die Entscheidungshoheit. Zwei Rollen musst du besetzen, sonst stockt das Projekt:

• Eine entscheidungsfähige Person: erreichbar, darf Ja und Nein sagen, sammelt nicht erst Meinungen im Haus.
• Eine Person mit Fachwissen: kennt die Ausnahmen im Prozess, die in keiner Dokumentation stehen.

Realistischer Aufwand auf deiner Seite: zwei bis vier Stunden pro Woche. Weniger führt zu Rückfragen, die Wochen kosten; mehr braucht es nicht.

Technologie ist ersetzbar, aber nicht kostenlos ersetzbar. Drei Entscheidungen wirken über Jahre:

• Sprache und Framework: ein verbreiteter Standard (TypeScript, React) hält den Markt für Nachfolger offen. Eigenbau-Frameworks binden dich an ihren Erbauer.
• Datenbank: relationale Datenbanken (Postgres) tragen fast jeden Anwendungsfall und lassen sich überall betreiben.
• Hosting-Region: EU-Verarbeitung inklusive Auftragsverarbeitungsvertrag ist bei personenbezogenen Daten kein Extra, sondern Grundlage — Details dazu im Hosting-Artikel.

1. Alles auf einmal bauen. Der Umfang wächst schneller als das Verständnis für das Problem.
2. Design vor Datenmodell. Schöne Bildschirme, die sich nicht abbilden lassen, werden zweimal bezahlt.
3. Kein Eigentum an Code und Accounts. Repository, Datenbank und Domain müssen auf deinen Namen laufen.
4. Keine Fehlerüberwachung. Ohne Monitoring erfährst du von Ausfällen durch Nutzerbeschwerden.
5. Übergabe ohne Dokumentation. Ein Projekt ist erst fertig, wenn ein fremder Entwickler es in einem Tag lokal starten kann.

Ein tragfähiges Angebot benennt nicht nur Leistungen, sondern Grenzen:

• ein definierter erster Umfang mit ausdrücklichen Nicht-Zielen
• Datenmodell und Rollen als eigener Arbeitsschritt
• Aussage zu Hosting-Region, Auftragsverarbeitung und Löschfristen
• Fehler-Monitoring und Protokolle ab Go-Live
• Übergabe von Code, Datenbank und Accounts in dein Eigentum
• ein benannter Weg für die Zeit nach dem Start

Wie wir das umsetzen, steht auf der Seite zu Apps & Software. Wenn du dein Vorhaben einordnen lassen willst, reicht ein kurzes Gespräch über das Kontaktformular.