Web-Apps7 Min. Lesezeit
MVP: Welche Funktionen gehören in die erste Version Ihrer Web-App?
Veröffentlicht Von Ichii GmbH
Inhalt
- Was ein MVP für ein kleines Unternehmen bedeutet
- Der Kerntest: Geht es auch ohne?
- Muss, Soll, Kann, Nicht jetzt: die MoSCoW-Methode
- Das Arbeitsblatt zum Kopieren
- Beispiel: eine Wunschliste wird zur ersten Version
- Was keine Funktion ist, aber in Version 1 gehört
- Was fast immer warten kann
- Die Liste „Nicht in Version 1“ schützt Ihr Budget
- Wie Sie über Version 2 entscheiden
- Wo der Einstiegspreis von Ichii passt
- Ihr nächster Schritt
In die erste Version Ihrer Web-App gehört nur, was Nutzer brauchen, um die eine Hauptaufgabe von Anfang bis Ende zu erledigen. Alles andere kann warten. Diese kleinste brauchbare Version nennt man MVP, kurz für Minimum Viable Product: ein Produkt mit so wenig Funktionen wie möglich, das trotzdem echten Nutzen stiftet.
Die Prüffrage für jede Funktion lautet: Kann der Nutzer seine Hauptaufgabe auch ohne sie erledigen – notfalls mit einem einfachen Umweg? Wenn ja, gehört sie nicht in Version eins. Ausnahmen sind Dinge, die keine Funktionen im engeren Sinn sind, aber vom ersten Nutzer an stimmen müssen: sichere Anmeldung, Datenschutzhinweise, Backups und grundlegende Barrierefreiheit.
Kurz gesagt
- Ein MVP ist die kleinste Version, mit der echte Nutzer die Hauptaufgabe erledigen können. Ein Klick-Prototyp ist es nicht.
- Der Kerntest für jede Funktion: Geht die Hauptaufgabe auch ohne sie?
- Ordnen Sie jede Funktion in Muss, Soll, Später oder Nicht in Version 1 ein. Die Liste „Nicht in Version 1“ schützt Ihr Budget.
- Sicherheit, Datenschutz, Backups und Barrierefreiheit sind keine Wunschfunktionen, sondern Pflicht ab Version eins.
Was ein MVP für ein kleines Unternehmen bedeutet
In Startup-Ratgebern dient ein MVP oft dazu, Investoren oder einen Markt zu testen. Für ein kleines Unternehmen geht es meist um etwas Bodenständigeres: ein internes Werkzeug oder einen kleinen Kundenbereich, der ab dem ersten Tag einen Ablauf zuverlässig erledigt.
Daraus folgt: Ihr MVP muss stabil und nutzbar sein. Es darf schlicht aussehen, wenig können und an manchen Stellen manuelle Schritte enthalten. Es darf aber nicht unsicher sein oder Daten verlieren.
Der Kerntest: Geht es auch ohne?
Formulieren Sie zuerst die Hauptaufgabe in einem Satz, zum Beispiel: „Ein Kunde meldet einen Auftrag, das Büro plant ihn ein und markiert ihn als erledigt.“ Dann prüfen Sie jede Funktion auf Ihrer Wunschliste mit drei Fragen:
- Kann der Nutzer die Hauptaufgabe ohne diese Funktion abschließen?
- Gibt es für die erste Zeit einen einfachen Umweg, etwa eine E-Mail, einen Export oder einen Anruf?
- Wie oft wird die Funktion gebraucht – täglich oder einmal im Quartal?
Funktionen, ohne die die Hauptaufgabe scheitert, sind Muss. Für alles, was einen vertretbaren Umweg hat oder selten gebraucht wird, lohnt sich das Warten.
Muss, Soll, Kann, Nicht jetzt: die MoSCoW-Methode
Die MoSCoW-Methode sortiert Anforderungen in vier Gruppen. Das Agile Business Consortium beschreibt die vier Gruppen so:
| Gruppe | Bedeutung | In Version 1? |
|---|---|---|
| Must have (Muss) | Ohne sie scheitert das Ergebnis | Ja |
| Should have (Soll) | Wichtig, aber es gibt einen Umweg | Nur, wenn Budget und Zeit es zulassen |
| Could have (Kann) | Wertvoll, aber nicht nötig | Meist nein, also „Später“ |
| Won't have this time (Nicht jetzt) | Bewusst diesmal nicht enthalten | Nein, aber schriftlich festgehalten |
Der Leitsatz dazu ist so einfach wie wirksam: Wenn alles Priorität hat, hat nichts Priorität. Seien Sie bei „Muss“ streng. Eine erste Version, in der fast alles Muss ist, ist keine erste Version, sondern das Gesamtprojekt.
Das Arbeitsblatt zum Kopieren
Vorlage
Arbeitsblatt: Umfang der ersten Version
| Funktion | Für wen? | Geht die Hauptaufgabe ohne sie? | Umweg für die erste Zeit | Einstufung (Muss / Soll / Später / Nicht in V1) |
|---|---|---|---|---|
| … | … | ja / nein | … | … |
| … | … | ja / nein | … | … |
| … | … | ja / nein | … | … |
| … | … | ja / nein | … | … |
- Hauptaufgabe in einem Satz: …
- Nicht in Version 1 (wird schriftlich ausgeschlossen): …
- Pflicht ab Version 1, unabhängig von Funktionen: sichere Anmeldung und Rechte, Datenschutzhinweise, Backups, beschriftete Formularfelder
- Wann wir über Version 2 entscheiden (Datum oder Anlass): …
Beispiel: eine Wunschliste wird zur ersten Version
Beispiel
Beispiel (hypothetisch): Auftragsportal für eine Gebäudereinigung
Ausgangslage: Eine Gebäudereinigung mit 15 Mitarbeitenden betreut Büros und Praxen. Sonderreinigungen werden per Telefon und E-Mail bestellt, Einsätze stehen in einer Excel-Tabelle. Die Inhaberin hat zwölf Wünsche gesammelt.
Hauptaufgabe: Ein Geschäftskunde bestellt eine Sonderreinigung, das Büro plant den Einsatz und meldet die Erledigung zurück.
| Funktion | Geht es ohne? | Einstufung |
|---|---|---|
| Bestellformular für Sonderreinigungen | Nein | Muss |
| Auftragsliste mit Status für das Büro | Nein | Muss |
| E-Mail an den Kunden bei Erledigung | Nein, sonst fragt der Kunde nach | Muss |
| Login für das Büro mit Rechten | Nein | Muss |
| Kundenkonten mit Auftragshistorie | Ja, Bestätigung per E-Mail reicht | Soll |
| Einsatzplan mit Kalenderansicht | Ja, vorerst weiter in Excel | Soll |
| Export für die Buchhaltung | Ja, Rechnungen laufen wie bisher | Später |
| Fotos vor und nach der Reinigung | Ja, per E-Mail möglich | Später |
| Mobile Ansicht für das Reinigungsteam | Ja, Einsatzzettel wie bisher | Später |
| Englische Oberfläche | Ja, alle Kunden sprechen Deutsch | Nicht in V1 |
| Online-Bezahlung | Ja, Rechnung wie bisher | Nicht in V1 |
| Auswertungen und Statistiken | Ja | Nicht in V1 |
Ergebnis: Version 1 besteht aus vier Funktionen statt zwölf. Sie löst das eigentliche Problem – verlorene Bestellungen und Rückfragen – und lässt sich nach einigen Wochen Nutzung gezielt erweitern.
Was keine Funktion ist, aber in Version 1 gehört
Manche Anforderungen tauchen auf keiner Wunschliste auf, weil sie selbstverständlich wirken. Sie lassen sich aber nicht auf später verschieben.
- Sichere Anmeldung und saubere Rechte: Fehlerhafte Zugriffskontrolle steht in der OWASP Top 10 (2025), der Referenzliste der kritischsten Sicherheitsrisiken von Webanwendungen, auf Platz eins; Fehler bei der Authentifizierung sind ebenfalls aufgeführt. Wer was sehen darf, muss ab dem ersten Nutzer stimmen.
- Datenschutzhinweise: Werden personenbezogene Daten erhoben, müssen Betroffene schon zum Zeitpunkt der Erhebung informiert werden, etwa über Zweck, Rechtsgrundlage und Empfänger (Art. 13 DSGVO).
- Nur nötige Daten: Weniger Felder in Version 1 sind nicht nur günstiger, sondern entsprechen auch dem Grundsatz der Datenminimierung (Art. 5 Abs. 1 lit. c DSGVO).
- Backups: Die DSGVO verlangt unter anderem, personenbezogene Daten nach einem Zwischenfall rasch wiederherstellen zu können (Art. 32). Klären Sie, wie gesichert wird und ob die Wiederherstellung getestet ist.
- Barrierefreie Grundlagen: Formularfelder brauchen Beschriftungen oder Anleitungen; das ist in der WCAG 2.2 ein Kriterium der Stufe A (3.3.2). Bietet Ihre App Verbrauchern Dienstleistungen im elektronischen Geschäftsverkehr an, kann zudem das Barrierefreiheitsstärkungsgesetz greifen. Kleinstunternehmen, die Dienstleistungen erbringen, sind davon ausgenommen. Lassen Sie das im Zweifel rechtlich prüfen.
Was fast immer warten kann
- Statistiken und Dashboards: Erst wenn genug Daten da sind, wissen Sie, welche Zahlen Sie wirklich brauchen.
- Feine Rollenmodelle: Zum Start reichen oft eine oder zwei Rollen.
- Live-Anbindungen: Ein Export, den Sie selbst weiterverarbeiten, überbrückt die ersten Monate.
- Eigene Apps für iOS und Android: Eine Web-App läuft im Browser auf allen Geräten.
- Eine zweite Sprache, wenn Ihre Nutzer heute alle dieselbe sprechen.
- Automatische Benachrichtigungen für jeden Sonderfall: Eine E-Mail für den wichtigsten Fall genügt meist.
Die Liste „Nicht in Version 1“ schützt Ihr Budget
Die Won't-Liste ist kein Eingeständnis, dass etwas fehlt. Sie ist eine Vereinbarung: Diese Punkte sind bewusst nicht enthalten. Halten Sie sie im Briefing und im Angebot schriftlich fest. So bleibt klar, was zum vereinbarten Preis gehört, und spätere Wünsche werden als eigene Erweiterung geplant statt nebenbei erwartet.
Wie Sie über Version 2 entscheiden
Legen Sie schon vor dem Start fest, wann Sie über Erweiterungen sprechen, etwa nach acht Wochen Nutzung. Sammeln Sie bis dahin, was Nutzer tatsächlich vermissen und wo die Umwege wirklich Zeit kosten. Dann gehen Sie das Arbeitsblatt erneut durch. Häufig rutschen dabei Funktionen nach unten, die anfangs dringend wirkten.
Wo der Einstiegspreis von Ichii passt
Konsequent gekürzte erste Versionen sind die Art von Projekt, für die Ichiis Einstieg gedacht ist: kleine, klar umrissene Web-Apps ab 1.999 € netto, einmalig. Was Ihre Version 1 kostet, steht erst im festen Angebot nach den vereinbarten Funktionen; jede Zeile, die Sie auf „Später“ verschieben, hält den Umfang kleiner. Komplexe Rollenmodelle, ERP-Anbindungen oder viele Schnittstellen sprengen diesen Rahmen. Hosting, Drittdienste und technische Wartung ab 29 € im Monat kommen separat hinzu.
Ihr nächster Schritt
Kopieren Sie das Arbeitsblatt, schreiben Sie Ihre Hauptaufgabe in einen Satz und ordnen Sie jede Funktion ein. Übertragen Sie das Ergebnis dann in Ihr Web-App-Briefing, und schicken Sie es mit einer Web-App-Anfrage. Wenn Sie wissen möchten, wie sich jede gestrichene Funktion auf den Aufwand auswirkt, lesen Sie Was kostet eine Web-App?. Für konkrete Fälle helfen Tabelle durch eine Web-App ersetzen und Kundenportal: die erste Version.
Quellen
- MoSCoW Prioritization Template and Poster — Agile Business Consortium, accessed 2026-10-09
- OWASP Top 10:2025 — OWASP Foundation, accessed 2026-10-09 (A01 Broken Access Control, A07 Authentication Failures)
- Art. 5 DSGVO – Grundsätze für die Verarbeitung personenbezogener Daten — dsgvo-gesetz.de (nichtamtliche Fassung), accessed 2026-10-09
- Art. 13 DSGVO – Informationspflicht bei Erhebung — dsgvo-gesetz.de (nichtamtliche Fassung), accessed 2026-10-09
- Art. 32 DSGVO – Sicherheit der Verarbeitung — dsgvo-gesetz.de (nichtamtliche Fassung), accessed 2026-10-09
- Understanding SC 3.3.2: Labels or Instructions (Level A) — W3C WAI, accessed 2026-10-09
- § 3 BFSG – Barrierefreiheit, Verordnungsermächtigung — gesetze-im-internet.de, accessed 2026-10-09 (Abs. 3: Ausnahme für Kleinstunternehmen)
- FAQ zum Barrierefreiheitsstärkungsgesetz — Bundesfachstelle Barrierefreiheit, accessed 2026-10-09
Weiterlesen
Web-Apps
Web-App-Briefing: So beschreiben Sie Ihre Idee – ohne Fachchinesisch
Rollen, Abläufe, Daten, Anbindungen und was ausdrücklich nicht dazugehört: Mit dieser Vorlage beschreiben Sie Ihre App-Idee so, dass Sie ein belastbares Angebot bekommen.
7 Min. Lesezeit
Web-Apps
Kundenportal: Was die erste Version wirklich können muss
Die kleinste sinnvolle Version eines Kundenportals: Funktionstabelle mit Rollen und Login, Datenschutz-Grundlagen und eine ehrliche Kauf-oder-Bau-Entscheidung.
7 Min. Lesezeit
Web-Apps
Excel durch eine Web-App ersetzen: Wann es sich lohnt – und wann nicht
Tabelle behalten, fertiges Tool nutzen oder eine eigene Web-App bauen? Mit Signal-Checkliste, Vergleichstabelle und einem hypothetischen Beispiel.
8 Min. Lesezeit
Web-Apps
Was kostet eine Web-App? Kostentreiber und Aufwand realistisch einschätzen
Rollen, Datenmodell, Schnittstellen und Betrieb bestimmen den Preis einer Web-App. So schätzen Sie den Aufwand ein, bevor Sie Angebote einholen.
7 Min. Lesezeit
Sie planen eine Web-App?
Beschreiben Sie kurz, was die Anwendung können soll. Kleine, klar umrissene Web-Apps ab 1.999 € netto; den Endpreis legen wir vor dem Start nach den vereinbarten Funktionen fest.