MVP-Entwicklung

MVP-Entwicklung für Startups und KMU

Von der Idee zu einem Produkt, das echte Nutzer verwenden, testen und bezahlen können. Ein enger Umfang, eine Architektur, die das Wachstum trägt, und Code, der Ihnen gehört.

shardana.ai entwickelt MVPs für Startups und KMU: Wir entwerfen und bauen die erste funktionierende Version eines digitalen Produkts, mit genau so vielen Funktionen, wie nötig sind, um es echten Nutzern vorzulegen und herauszufinden, ob es funktioniert. Das Studio hat seinen Sitz in Cabras in der Provinz Oristano und arbeitet mit Gründern und Unternehmen in ganz Italien, überwiegend remote.

Viele MVPs gehen verloren, bevor sie die Nutzer erreichen. Der Umfang wächst mit jedem Meeting, der Stack wird nach Mode gewählt, der erste Entwickler verlässt das Projekt und niemand sonst versteht den Code. Oder es passiert das Gegenteil: Eine fragile Demo geht online und hält den ersten hundert Anmeldungen nicht stand. Unsere Arbeit liegt dazwischen: wenig bauen, und das gut.

Was ist ein MVP, und was ist es nicht?

Ein MVP (Minimum Viable Product) ist die kleinste Version eines Produkts, mit der sich eine Markthypothese mit echten Nutzern überprüfen lässt. „Minimal“ bezieht sich auf die Funktionen, nicht auf die Qualität: wenige Dinge, so gebaut, dass sie jedes Mal funktionieren. Ein MVP ist kein klickbarer Prototyp, der eine Idee zeigt, sich aber nicht benutzen lässt, und auch nicht die Version 1.0 mit allem, was Sie eines Tages anbieten möchten. Es ist ein echtes Produkt, mit Nutzern, Daten, Authentifizierung und, falls nötig, Zahlungen, reduziert auf den Weg, der den Nutzen beweist. Für einen Marktplatz kann es genügen, Angebot und Nachfrage in einer einzigen Kategorie zusammenzubringen; für eine Abo-Software, einen einzigen Arbeitsablauf für einen einzigen Kundentyp zu automatisieren. Alles andere wird ausdrücklich verschoben, bis die Daten zeigen, dass es sich lohnt, es zu bauen.

AspektPrototypMVPProdukt 1.0
Wozu er dientEine Idee zeigen und Reaktionen sammelnEine Hypothese mit echten Nutzern überprüfenEinen bereits validierten Markt bedienen
Wer ihn nutztTeam, Investoren, wenige TesterErste Kunden oder PilotnutzerAlle Kunden
Was er enthältBildschirme, TestdatenEin vollständiger Weg, echte Daten, grundlegende SicherheitMehrere Wege, Integrationen, strukturierter Support

Wann lohnt sich die Entwicklung eines MVP, und wann nicht?

Sie lohnt sich, wenn Sie eine genaue Hypothese überprüfen wollen und eine Nutzergruppe haben, die Sie wirklich erreichen: eine Branche, die Sie kennen, eine Warteliste, die bestehenden Kunden Ihres Unternehmens. Sie lohnt sich, wenn Sie Investoren oder Partnern Traktion mit echten Zahlen statt mit Folien zeigen müssen. Sie lohnt sich auch für ein KMU, das einen neuen digitalen Service einführen möchte, ohne das Tagesgeschäft anzuhalten, oder einen Prozess, den es heute von Hand erledigt, in ein Produkt verwandeln will.

Sie lohnt sich nicht, wenn sich die Hypothese ohne eine Zeile Code überprüfen lässt. Oft verrät eine Präsentationsseite mit Buchungsformular oder ein Service, der für die ersten zehn Kunden von Hand erbracht wird, in zwei Wochen, was ein MVP in zwei Monaten verraten würde. Das sagen wir Ihnen im ersten Gespräch: Ein Projekt, das ohne Grund startet, kostet Sie Geld und nützt uns nichts.

Wie wird ein MVP entwickelt, Phase für Phase?

Die Phasen sind immer dieselben; es ändert sich nur, wie lange sie dauern. Die Tabelle zeigt unseren typischen Ablauf für ein Web-MVP mittlerer Komplexität, rund sechs Wochen. Es ist ein Referenzmodell, keine vertragliche Zusage: Die tatsächlichen Zeiten werden im Angebot nach der Discovery festgelegt und hängen von Umfang, Integrationen und der Geschwindigkeit der Entscheidungen ab.

PhaseTypischer ZeitraumWas passiertWas Sie erhalten
DiscoveryWoche 1Hypothese, Nutzer, kritischer Pfad, Kennzahlen, RahmenbedingungenUmfangsdokument: drin, draußen, später
ArchitekturWochen 1–2Stack, Datenmodell, externe Dienste, UmgebungenDokumentierte Architektur und priorisiertes Backlog
Inkrementelle EntwicklungWochen 2–5Wöchentliche Releases in eine Testumgebung, Demos und FeedbackEin Produkt, das jede Woche wächst
Quality Gate und LaunchWoche 6Tests, Sicherheit, Performance, MessungEin messbares Produkt in Produktion
ÜbergabeNach dem LaunchDokumentation, Zugänge, Sitzung mit Ihrem TeamEin Produkt, das Sie mit wem Sie wollen weiterentwickeln können

1. Discovery: entscheiden, was nicht gebaut wird

Die Discovery beginnt mit einer Frage: Welche Hypothese soll dieses MVP belegen? Davon ausgehend legen wir mit Ihnen fest, an welchen Nutzer es sich richtet, welcher kritische Pfad gilt (vom ersten Login bis zu dem Moment, in dem der Nutzer den versprochenen Nutzen erhält) und welche Kennzahlen zeigen, ob die Hypothese trägt: wie viele den Pfad abschließen, wie viele zurückkommen, wie viele zahlen. Wir sammeln auch die Rahmenbedingungen: personenbezogene Daten, Zahlungen, verpflichtende Integrationen, externe Fristen. Das Ergebnis ist ein kurzes Umfangsdokument mit drei Spalten: was ins MVP kommt, was draußen bleibt und was später kommt. In dieser Phase sparen Sie am meisten, denn jede Funktion, die hier wegfällt, ist Arbeit, die Sie nicht bezahlen.

2. Architektur: heute einfach, morgen erweiterbar

Ein MVP braucht keine Microservices, Cluster und zehn Umgebungen. Es braucht eine einfache Architektur, die nicht zwingt, alles neu zu schreiben, wenn die ersten Kunden kommen. Meist bedeutet das eine responsive Webanwendung oder eine PWA vor einer nativen App, eine einzige, in Module gegliederte Anwendung, eine relationale Datenbank und etablierte externe Dienste für Authentifizierung, Zahlungen und E-Mail. Der Referenz-Stack umfasst PHP und Laravel, Node.js und TypeScript, React und Vue.js, MySQL. Die wichtigsten Entscheidungen landen in einem kurzen Entscheidungsprotokoll: Wer später dazukommt, weiß, warum das System so gebaut ist.

3. Inkrementelle Entwicklung: ein Release pro Woche

Die Entwicklung erfolgt in wöchentlichen Releases in eine Testumgebung, auf die Sie Zugriff haben. Jede Woche sehen Sie das Produkt wachsen, testen es und entscheiden mit uns die Prioritäten der folgenden Woche. Das Backlog ist gemeinsam und priorisiert: Wenn Feedback die Prioritäten ändert, wird etwas nach hinten verschoben, statt das Projekt zu verlängern. Kein zweimonatiger Tunnel mit einer Überraschung am Ende.

4. Quality Gate: was wir vor dem Go-live prüfen

Vor dem Launch durchläuft das Produkt eine Reihe von Prüfungen, die zu Beginn vereinbart werden. Automatisierte Tests der kritischen Pfade wie Registrierung, Zahlung und Hauptaktion. Code-Review. Grundlegende Sicherheitsprüfungen zu Authentifizierung, Berechtigungen, personenbezogenen Daten und Backups. Performance auf Smartphones. Bereits aktive Analytics-Events, um ab dem ersten Tag die in der Discovery festgelegten Kennzahlen zu messen. Fehlerprotokollierung und Monitoring. Wenn eine blockierende Prüfung nicht bestanden wird, verschiebt sich der Launch: Diese Regel legen wir gemeinsam fest, bevor die erste Zeile geschrieben wird.

5. Übergabe: Das Produkt gehört Ihnen

Ein MVP, das nur derjenige betreiben kann, der es geschrieben hat, ist ein Risiko für Ihr Unternehmen. Deshalb liegt der Code in einem Repository auf Ihren Namen, die Konten für Infrastruktur und externe Dienste gehören Ihnen und die Dokumentation erklärt, wie das Projekt gestartet, veröffentlicht und aufgebaut ist. Zum Abschluss gibt es eine Übergabesitzung mit Ihrem Team oder mit denen, die das Produkt betreuen werden. Danach haben Sie die Wahl: es mit uns weiterentwickeln, ein internes Team einbinden oder allein weitermachen.

Was erhalten Sie am Ende der MVP-Entwicklung?

  • Das Produkt in Produktion, mit Domain und Infrastruktur auf Ihren Namen.
  • Den Quellcode in Ihrem Repository, mit der vollständigen Änderungshistorie.
  • Drei getrennte Umgebungen: Entwicklung, Test und Produktion.
  • Die technische Dokumentation: lokaler Start, Release, Architektur und getroffene Entscheidungen.
  • Das Dashboard mit den in der Discovery vereinbarten Kennzahlen.
  • Den Bericht des Quality Gates, mit den bestandenen Prüfungen und den bekannten Einschränkungen.
  • Das Backlog der verschobenen Funktionen, priorisiert nach dem, was Sie von den Nutzern gelernt haben.

Ein Beispiel für den Umfang

Ein illustratives Beispiel, kein Kundenfall. Ein Startup möchte prüfen, ob lokale Guides dafür bezahlen würden, provisionsfreie Buchungen für Ausflüge zu erhalten. Ins MVP kommen die Ausflugsseite, der Verfügbarkeitskalender, die Buchung mit Online-Zahlung, die Bestätigung per E-Mail und ein schlankes Dashboard für den Guide. Draußen bleiben die native App, Bewertungen, Chat und Treueprogramm. Später kommen, wenn die Zahlen es rechtfertigen, Gruppenangebote und die Anbindung externer Vertriebskanäle. Die Hauptkennzahl ist eine einzige: wie viele der eingeladenen Guides im ersten Monat mindestens eine bezahlte Buchung erhalten.

Was brauchen wir von Ihnen für den Start?

Vor allem eine Person, die entscheidet. Ein MVP wird eher durch eine aufgeschobene Entscheidung gebremst als durch einen Bug: Wir bitten darum, dass der Gründer oder die Produktverantwortliche an den wöchentlichen Demos teilnimmt und Fragen innerhalb weniger Tage beantwortet. Außerdem brauchen wir Zugang zu einigen Nutzern für Tests, die Inhalte und Texte des Produkts und Konten auf den Namen des Unternehmens: Domain, Cloud-Dienste, Zahlungsanbieter. Wenn Sie bereits Mockups, Marktstudien oder eine frühere Version haben, bringen Sie sie zum ersten Treffen mit: Wir nutzen sie und fangen nicht bei null an.

Was kostet die Entwicklung eines MVP?

Die Kosten eines MVP hängen vom vereinbarten Umfang ab, deshalb veröffentlichen wir keine Preisliste, die für alle gilt. Ins Gewicht fallen vor allem die Zahl der Nutzertypen und Pfade, Integrationen mit externen Systemen (Zahlungen, Warenwirtschaft, APIs von Drittanbietern), Komponenten mit künstlicher Intelligenz, Anforderungen an Sicherheit und Compliance, die abzudeckenden Plattformen und der Stand des Designs, fertig oder noch zu entwerfen. Hinzu kommen die laufenden Kosten für Hosting, externe Dienste und gegebenenfalls KI-Modelle, die mit der Nutzung wachsen und von Anfang an geschätzt werden müssen. Nach dem ersten Gespräch erhalten Sie ein schriftliches Angebot mit Phasen, Ergebnissen und Kosten, und Sie können mit der Discovery allein beginnen, bevor Sie sich auf die gesamte Entwicklung festlegen.

FaktorEinfacheres MVPKomplexeres MVP
Nutzer und PfadeEin Nutzertyp, ein PfadMehrere Rollen mit unterschiedlichen Berechtigungen
IntegrationenZahlung und E-MailWarenwirtschaft, externe APIs, Synchronisierungen
PlattformenResponsive Web oder PWAWeb plus native Apps
Künstliche IntelligenzKeine oder in einer FunktionIm Zentrum des Produkts
DesignOberfläche bereits definiertVon Grund auf zu entwerfen

Lässt sich ein MVP mit künstlicher Intelligenz entwickeln?

Ja, wenn die künstliche Intelligenz der Nutzen des Produkts ist und kein Etikett. Ein Assistent, der zu den Dokumenten einer Branche antwortet, ein System, das Daten aus Rechnungen oder Verträgen extrahiert, eine Suche, die die Bedeutung von Fragen versteht: In diesen Fällen muss die KI sofort überprüft werden, weil sie die riskanteste Hypothese ist. In der Discovery legen wir fest, wie die Qualität der Antworten gemessen wird und was jede Nutzung der Modelle kosten wird. Wenn die KI dagegen das Nutzererlebnis nicht verändert, lassen wir sie in der ersten Version weg. Bei Projekten, in denen KI das Herz des Systems ist, arbeiten wir mit derselben Methode wie bei der KI-Entwicklung für Unternehmen; wenn das MVP ein internes Werkzeug ist, das E-Mail, CRM und Warenwirtschaft verbinden muss, sehen Sie sich auch die KI-Automatisierung von Geschäftsprozessen an.

Mit welcher Erfahrung arbeiten wir?

shardana.ai wurde 2026 gegründet, doch die Arbeit stützt sich auf mehr als 25 Jahre Erfahrung des Gründers Maurizio Brioschi in Softwareentwicklung, Backend-Entwicklung, Systemarchitektur und der Leitung technischer Teams. Bei MVPs dient diese Erfahrung vor allem dazu, zu entscheiden, was man nicht tut: welche Funktion verschoben wird, welcher externe Dienst genutzt wird, statt ihn neu zu schreiben, welche Abkürzung zu einer schwer abzutragenden Schuld wird. Wir veröffentlichen keine Kundenfälle, die wir nicht belegen können: Im ersten Gespräch gehen wir auf die technischen Entscheidungen für Ihre Idee ein.

Wo arbeiten wir?

Wir arbeiten mit Startups und KMU in ganz Italien, größtenteils remote: Discovery, wöchentliche Demos und Releases funktionieren online gut. Der Sitz ist in Cabras in der Provinz Oristano, und für Projekte auf Sardinien lassen sich persönliche Treffen vereinbaren, angefangen beim Discovery-Workshop.

Häufig gestellte Fragen

Wie lange dauert die Entwicklung eines MVP?
Für ein Web-MVP mittlerer Komplexität dauert unser typischer Ablauf rund sechs Wochen, von der Discovery bis zum Launch. Das ist ein Richtwert, keine Garantie: Komplexe Integrationen, native Apps oder langsame Entscheidungen verlängern die Zeit, ein sehr enger Umfang verkürzt sie. Den Zeitplan Ihres Projekts legen wir im Angebot nach der Discovery fest.
No-Code-Werkzeug oder individuelle Entwicklung?
Das hängt davon ab, was Sie überprüfen müssen. No-Code-Werkzeuge eignen sich, um eine Idee schnell zu validieren, wenn die Logik einfach und die Volumen gering sind. Individuelle Entwicklung lohnt sich, wenn das Produkt eine eigene Logik hat, sich in andere Systeme integrieren oder ohne Neuschreiben wachsen muss. Manchmal ist No-Code der richtige Start: Dann sagen wir es Ihnen.
Gehört der Quellcode mir?
Ja. Der Code liegt in einem Repository auf den Namen Ihres Unternehmens, und die Rechte werden vor Beginn im Vertrag geregelt. Auch die Konten für Infrastruktur und externe Dienste laufen auf Ihren Namen.
Können Sie mit unserem internen Technikteam arbeiten?
Ja. Wir können das MVP entwickeln und an Ihr Team übergeben oder von Anfang an zusammenarbeiten, mit gemeinsamen Code-Reviews und gemeinsam getroffenen Architekturentscheidungen.
Was passiert nach dem Launch?
Wir analysieren mit Ihnen die in der Discovery festgelegten Kennzahlen und priorisieren das Backlog nach dem, was die Nutzer tatsächlich tun. Sie können die Entwicklung mit uns fortsetzen, sie Ihrem Team übertragen oder aufhören, wenn die Daten zeigen, dass die Hypothese nicht trägt.
Entwickeln Sie auch mobile Apps?
Ja, aber für ein MVP beginnen wir fast immer mit einer responsiven Webanwendung oder einer PWA, die sich aus dem Browser installieren lässt: Das kostet weniger und aktualisiert sich ohne App-Stores. Zu nativen Apps wechseln wir, wenn Smartphone-Funktionen gebraucht werden, die das Web nicht bietet. Details finden Sie auf der Seite zu mobilen Apps und PWAs.

Verwandte Leistungen

Erzählen Sie uns von der Idee, die Sie auf die Probe stellen wollen

Beschreiben Sie das Produkt, für wen es gedacht ist und welche Hypothese Sie überprüfen möchten. Wir antworten mit einer ersten Einschätzung und, wenn es sinnvoll ist, mit einem Vorschlag für die Discovery.