Web-App erstellen: der Leitfaden für Gründer zum eigenen MVP

Wenn Sie sich fragen, wie Sie eine Web-App für ein neues Produkt erstellen, lautet die kurze Antwort: Bauen Sie ein Minimum Viable Product. Wählen Sie eine einzige Nutzerreise, bauen Sie eine Web-App, die diese von Anfang bis Ende abschließt, und bringen Sie sie innerhalb von Wochen, nicht Monaten, vor echte Nutzer. Alles andere – die zweite Funktion, die mobile App, die Integrationen – wartet, bis Sie gesehen haben, wie Menschen die erste Version benutzen.

Dieser Leitfaden ist für Gründer, die ein funktionierendes Produkt wollen, keinen Prototyp fürs Pitch-Deck: was ein MVP ist und was nicht, wie man ein MVP mit einem Umfang baut, den man fertigstellen kann, was eine erste Version enthalten muss, was die MVP-Entwicklung kostet und was nach dem Launch zu planen ist.

Was ein MVP ist – und was nicht

Bevor Sie entscheiden, wie Sie Ihr MVP entwickeln, sollten Sie genau wissen, was eines ist. Ein Minimum Viable Product ist die kleinste Version Ihres Produkts, mit der ein echter Kunde ein echtes Ergebnis erzielen kann. „Viable“ – tragfähig – ist das Wort, das gern vergessen wird. Ein MVP ist kein klickbares Mock-up, keine Landingpage mit Warteliste und keine halbfertige Plattform mit zehn Funktionen, die jeweils zu 60 % funktionieren.

Eine Minimum-Viable-Product-Web-App ist auf einem Pfad vollständig und auf allen anderen stumm. Ein Nutzer registriert sich, tut das eine, was Ihr Produkt verspricht, und sieht das Ergebnis. Funktioniert dieser Pfad, haben Sie etwas, aus dem Sie lernen können.

MVP entwickeln: den Umfang auf eine Nutzerreise reduzieren

Am Umfang scheitern die meisten ersten Produkte, noch bevor eine Zeile Code geschrieben ist. Schreiben Sie die eine Reise auf, die ein zahlender Nutzer vom Aufruf Ihrer App bis zum Nutzen zurücklegt, und bauen Sie nur diese:

1. Formulieren Sie das Versprechen in einem Satz. „Ein Freelancer lädt Belege hoch und erhält einen monatlichen Ausgabenbericht.“
2. Listen Sie jeden Bildschirm auf, den dieser Satz braucht. Meist fünf bis acht, nicht dreißig.
3. Notieren Sie pro Bildschirm, was der Nutzer tun können muss. Alles, was als „nett“ markiert ist, kommt auf eine Parkliste.
4. Fragen Sie bei jedem verbleibenden Punkt: Bekäme der Nutzer das Ergebnis auch ohne ihn? Wenn ja, streichen.

Teamrollen, eine native mobile App, Social Login und eine öffentliche API fallen in diesem Schritt meist heraus. Sie können später wichtig werden; nichts davon sagt Ihnen, ob die Kernidee funktioniert. Die Parkliste ist die Roadmap für die Monate nach dem Launch.

Web-App erstellen: No-Code oder eigener Code?

Die erste Weggabelung ist die Frage, ob Sie mit einem No-Code-Werkzeug bauen oder eine eigene Web-App für Ihr Startup entwickeln lassen. Beides ist legitim; die falsche Wahl ist die teure.

Unsere Faustregel: Besteht das Produkt aus einem Formular, einer Liste und einem Dashboard, starten Sie mit No-Code. Ist das Produkt die Logik – Matching, Preisberechnung, Workflows, alles, bei dem Geld fließt – bauen Sie von Anfang an eine eigene Web-App; ein No-Code-MVP neu zu bauen, das abgehoben hat, ist ein häufiges und vermeidbares Projekt.

Der Stack ist weniger wichtig als der Umfang

Die häufigste Frage, die wir zum Thema MVP entwickeln hören, betrifft das Framework. Für ein MVP ist sie fast unerheblich. Ein typischer Stack besteht heute aus einem TypeScript-Frontend (Next.js oder ähnlich), einer verwalteten Postgres-Datenbank, einem gehosteten Auth-Anbieter, Stripe für Zahlungen und Hosting in einer europäischen Region: unspektakulär, gut dokumentiert und günstig im Betrieb.

Wichtiger ist: Das Team kann die App pflegen oder sauber übergeben, die Daten liegen in der EU und sind exportierbar, das Hosting bleibt unter ein paar hundert Euro im Monat, und ein zweiter Entwickler kann den Code in einem Jahr noch lesen.

Was eine erste Version enthalten muss

Den Umfang zu kürzen heißt nicht, die langweiligen Teile zu streichen. Eine Minimum-Viable-Product-Web-App, die echte Menschen nutzen, braucht ein Fundament an Funktionen, das nichts mit Ihrer Idee zu tun hat und alles mit dem Betrieb eines Produkts:

• Authentifizierung. Registrierung, Login, Passwort zurücksetzen, Konto löschen. Nutzen Sie einen gehosteten Anbieter.
• Der Kernablauf. Die eine Reise aus der Umfangsübung, von Anfang bis Ende fertig, mit leeren Zuständen und Fehlermeldungen.
• Zahlungen, wenn Sie Geld verlangen. Stripe oder ein lokales Pendant, ein Tarif, Rechnungen, die eine Buchhaltung akzeptiert.
• Eine Admin-Ansicht. Eine Seite, auf der Sie Nutzer sehen, was sie getan haben, und einen Datensatz korrigieren können, ohne die Datenbank zu öffnen. Gründer überspringen das und bereuen es in Woche eins.
• Analytics und Fehlerüberwachung. Die drei oder vier Ereignisse, die den Abschluss der Reise zeigen, und ein Fehlertracker, der Ihnen eine E-Mail schickt, wenn etwas kaputtgeht.
• Das rechtliche Minimum. Datenschutzerklärung, AGB, ein Cookie-Hinweis, der zu dem passt, was Sie laden. In der EU ist das nicht optional.

Ein MVP braucht kein Designsystem, aber der Kernablauf muss auf dem Handy klar sein. Eine kurze Phase Produktdesign vor der Entwicklung – Nutzerflüsse, Wireframes, eine visuelle Richtung – zahlt sich aus, weil sie Bildschirme entfernt, die sonst gebaut und weggeworfen würden.

MVP entwickeln in 6–8 Wochen: ein realistischer Zeitplan

Mit festem Umfang, einem kleinen Team und einem Gründer, der Fragen am selben Tag beantwortet, passt ein eigenes MVP in sechs bis acht Wochen.

Die sechs bis acht Wochen unten decken ein vollständiges MVP ab: Design, Zahlungen, eine Admin-Ansicht und einen Pilotbetrieb mit echten Nutzern. Eine kleinere erste Version – ein Ablauf ohne Zahlungen – kann kürzer sein; bei Pazl kann ein erster Lieferplan bei rund vier Wochen liegen, sobald Umfang und Zulieferungen stehen. Wie wir diese Wochen organisieren, beschreibt MVP in vier Wochen: unser Entwicklungsprozess.

So teilen wir es auf:

Was diesen Plan dehnt, sind Umfang, der mitten in der Entwicklung dazukommt, und langsame Entscheidungen: Ein Gründer, der wöchentlich prüft und innerhalb eines Tages antwortet, hält den Zeitplan. Ist Ihre Idee ein Portal für bestehende Kunden statt eines neuen Produkts, gilt derselbe Zeitplan; diese Variante beschreiben wir bei unserem Service Kundenportal, der ebenfalls ab 2.500 € beginnt.

MVP-Entwicklungskosten: was den Preis bestimmt

Die Kosten der MVP-Entwicklung hängen vor allem vom Umfang ab und davon, wer baut. Grobe Marktspannen in Europa 2026 nach unserer Einschätzung: ein Freelancer typischerweise 3.000–15.000 €, mit großer Streuung bei der Qualität; ein kleines Studio typischerweise 5.000–30.000 € für ein eigenes MVP mit den sechs Grundbausteinen oben; eine größere Agentur oft 30.000–80.000 €.

Bei Pazl beginnt eine Web-App oder ein MVP ab 2.500 € zum Festpreis, mit Senior-Review und sechs Monaten Garantie; Produktdesign beginnt ab 1.200 €. Was der Startumfang enthält, sehen Sie auf unserer Seite zur MVP-Entwicklung. Die Zahl steigt mit den Bildschirmen, Integrationen und Rollen, nicht mit den Ideen im Deck.

Was die Kosten nach oben treibt, nach Wirkung sortiert: Integrationen mit externen Systemen (Buchhaltung, CRM, Logistik), Rollen und Berechtigungen, Echtzeitfunktionen, individuelles Design statt einer Komponentenbibliothek und eine native mobile App neben der Web-App. Einen breiteren Blick gibt unser Leitfaden Was kostet es, 2026 eine App zu entwickeln.

Ein MVP mit echten Nutzern testen

Zu wissen, wie man ein MVP entwickelt, ist die halbe Arbeit; es zu testen die andere Hälfte. Ein MVP, das nur Ihr Team benutzt hat, ist nicht getestet. Planen Sie den Pilot, bevor die Entwicklung endet:

• Gewinnen Sie fünf bis zehn Nutzer aus Ihrem bestehenden Umfeld – Newsletter, Community, bestehende Kunden. Keine Freunde.
• Geben Sie ihnen eine Aufgabe in einem Satz, das Versprechen aus der Umfangsübung, und sonst nichts.
• Sehen Sie dreien davon live per Bildschirmfreigabe zu. Sagen Sie nichts; wo sie zögern, liegt Ihre nächste Iteration.
• Messen Sie den Rest mit Ihren Ereignissen: Wie viele haben begonnen, abgeschlossen und kamen innerhalb einer Woche zurück?

Schließen die meisten Nutzer die Reise ab und einige kommen zurück, haben Sie ein Produkt. Schließen sie ab und kommen nie wieder, haben Sie eine Funktion. Können sie nicht abschließen, reparieren Sie den Ablauf, bevor Sie irgendetwas hinzufügen.

Häufige Fehler, wenn Sie eine Web-App erstellen

• Die zweite Nutzerreise bauen, bevor die erste funktioniert. Team-Konten, Benachrichtigungen und eine Einstellungsseite wirken unverzichtbar. Sie sind es nicht, solange nicht ein Nutzer den Kernablauf ohne Hilfe abgeschlossen hat.
• Keine Admin-Ansicht. In der ersten Woche braucht jemand ein neues Passwort oder eine Erstattung. Ohne Admin-Seite wird jede Anfrage zu einer Datenbankabfrage.
• Den Stack vor dem Umfang wählen. Framework-Debatten dauern Wochen und ändern für den Nutzer nichts. Ein langweiliger, gut dokumentierter Stack ist die richtige Voreinstellung.
• Zahlungen über ein selbst gebautes Kartenformular. Nutzen Sie den gehosteten oder eingebetteten Checkout des Anbieters; er übernimmt die starke Kundenauthentifizierung für Sie. Mehr dazu in Zahlungen online annehmen.
• Vor Freunden launchen. Freunde sind höflich. Fünf Fremde, die das Problem haben, das Sie lösen, sagen Ihnen in einer Woche mehr.
• Code und Konten nicht besitzen. Domain, Hosting, Repository, Zahlungskonto – alles vom ersten Tag an auf den Namen Ihres Unternehmens.

Checkliste, bevor Sie einen Entwickler briefen

• Das Produktversprechen passt in einen Satz.
• Die zentrale Nutzerreise ist als Liste von Bildschirmen aufgeschrieben (meist fünf bis acht).
• Alles andere steht auf einer Parkliste, mit einem Grund, warum es warten kann.
• Wir wissen, ob Nutzer in Version eins bezahlen, und wie.
• Wir wissen, wer eine Admin-Ansicht braucht und was er dort beheben können muss.
• Wir haben einen Budgetrahmen und ein Launch-Datum, das wir akzeptieren würden.
• Wir haben fünf bis zehn echte Nutzer für den Pilotbetrieb.
• Wir wissen, wer die Nutzer nach dem Launch betreut.

Ein Entwickler, der diese Liste bekommt, kann Ihnen einen Festpreis nennen. Einer, der ein Pitch-Deck bekommt, kann nur raten.

Nach dem Launch: Support und Iterationen

Der Launch ist der Beginn des teuren Teils, nicht das Ende des Projekts. Planen Sie drei Dinge.

Support. Jemand antwortet Nutzern innerhalb eines Tages, und jemand kann an einem Samstag ein kaputtes Deployment reparieren. In den ersten Monaten ist das oft der Gründer plus das Studio mit einer kleinen Pauschale; siehe Produktsupport nach dem Launch.

Iterationen. Nehmen Sie die Parkliste, streichen Sie, was der Pilot als unnötig gezeigt hat, und liefern Sie alle ein bis zwei Wochen eine Verbesserung aus.

Die nächste Schwelle. Irgendwann ist das MVP nicht mehr minimal: mehr Rollen, ein Kundenbereich, eine mobile Begleit-App. Das ist der Moment, die Architektur neu anzuschauen, statt anzubauen. Wenn Ihr nächster Schritt ein Login-Bereich für bestehende Kunden ist, lesen Sie was ein Kundenportal ist und wann Sie eines brauchen. Unser Artikel darüber, wann eine Landingpage nicht mehr reicht, beschreibt denselben Übergang eine Stufe früher, und unser Projekt Numera Ledger zeigt eine so gebaute Finanz-Web-App.

Häufig gestellte Fragen

Wie lange dauert es, ein MVP zu entwickeln?

Mit einem festen Umfang von einer Nutzerreise dauert eine eigene Web-App sechs bis acht Wochen vom Workshop bis zum Launch. No-Code-Versionen können in Tagen fertig sein, müssen aber meist neu gebaut werden, wenn das Produkt wächst.

Was kostet ein MVP?

Nach unserer Einschätzung reichen die Marktpreise in Europa von etwa 3.000 € bei einem Freelancer bis 80.000 € und mehr bei einer großen Agentur. Bei Pazl beginnt eine Web-App oder ein MVP ab 2.500 € zum Festpreis, Produktdesign ab 1.200 €.

Soll ich das MVP als Web-App oder als mobile App bauen?

Fast immer zuerst als Web-App: Sie läuft auf jedem Handy, braucht keine App-Store-Prüfung und lässt sich am selben Tag ändern. Eine native App lohnt sich, wenn Nutzer Push-Benachrichtigungen, Offline-Nutzung oder die Kamera im Kernablauf brauchen. Unsere mobilen Apps beginnen ab 4.750 €.

Kann ich mit No-Code starten und später auf eigene Entwicklung wechseln?

Ja, wenn das Produkt hauptsächlich aus Formularen und Listen besteht. Der Wechsel ist ein Neubau, keine Migration: Die Daten kommen mit, die Logik wird neu geschrieben. Liegt der Wert in der Logik oder nehmen Sie vom ersten Tag an Zahlungen entgegen, ist der eigene Start über zwölf Monate meist günstiger.

Brauche ich einen technischen Mitgründer, um eine Web-App zu erstellen?

Nicht für die erste Version. Sie brauchen jemanden, der die Produktentscheidungen verantwortet – meist Sie selbst – und einen Entwickler oder ein Studio, das die Umsetzung verantwortet. Ein technischer Mitgründer wird wichtig, sobald das Produkt funktioniert und Sie ein eigenes Team aufbauen.

Was ist der Unterschied zwischen einer Web-App und einer Website?

Eine Website zeigt vor allem Informationen: Seiten, Artikel, ein Kontaktformular. Mit einer Web-App erledigen Nutzer etwas, und sie speichert ihre Daten: anmelden, Einträge anlegen, bezahlen, den Verlauf sehen. Die meisten MVPs sind Web-Apps, auch wenn sie wie eine einfache Website aussehen.