Ein digitales Produkt solo in 30 Tagen bauen: ein ehrlicher Rückblick

Kurz gesagt — Ein digitales Produkt solo in 30 Tagen zu bauen ist machbar — aber nicht aus den Gründen, die man gemeinhin annimmt: KI ersetzt kein strategisches Denken, sie beschleunigt die Umsetzung, sobald du genau weißt, was du bauen willst. Der eigentliche Flaschenhals ist nicht der Code — es ist die Entscheidung.

Dreißig Tage. Ein einziger Dev. Kein Mitgründer, kein Marketingbudget, kein Meeting. Das ist kein Twitter-Challenge. Das ist die Realität eines Solo-Indie-Studios — und es ist komplizierter und lehrreicher, als es irgendein Thread mit 280 Zeichen zusammenfassen könnte.

Dieser Rückblick ist chronologisch aufgebaut, wo möglich mit Zahlen belegt und ehrlich über die Momente, in denen es fast aus dem Ruder gelaufen wäre. Wer glatte Inspiration sucht, ist hier falsch. Wer verstehen will, wie ein digitales Produkt im KI-Zeitalter wirklich solo entsteht, liest weiter.

Woche 1: Idee wählen und validieren — ohne Code anzufassen

In der ersten Woche wird nicht gecoded. Wer in Woche 1 anfängt zu coden, hat schon verloren.

Meine Regel: keine einzige Zeile Code, bevor ich einen — auch minimalen — Beweis habe, dass jemand das Problem hat und nach einer Lösung sucht. Kein „interessant”, sondern eine echte, dokumentierte Reibung.

Wie ich die Idee finde

Ich starte immer bei einem Schmerz, den ich selbst erlebt oder direkt in meiner Arbeit als Freelance-Dev beobachtet habe. Ideen aus dem Nichts haben eine Abbruchrate nahe 100 % — zumindest bei kurzen Sprints. Wenn das Problem für dich real ist, überwindest du die Blockaden in Woche 3, weil du die Lösung genauso willst wie deine künftigen Nutzer.

Konkret: Ich liste alle Aufgaben auf, die mich in den letzten 90 Tagen Zeit oder Energie gekostet haben. Keine abstrakten Ideen — konkrete Momente, in denen ich dachte: „Dafür sollte es ein Tool geben.”

Validierung in 5 Tagen mit KI

KI kommt hier ins Spiel — aber nicht als Entwickler. Sie übernimmt die Rolle eines kritischen Sparringspartners.

Tag 1–2: Das Problem präzise definieren. Ich beschreibe das Problem einem Sprachmodell und bitte es, mir so lange Fragen zu stellen, bis die Definition eindeutig ist. Diese Übung dauert 1 bis 2 Stunden und legt systematisch blinde Flecken in meiner ursprünglichen Formulierung frei.

Tag 3: Alternativen kartieren. Ich bitte die KI, alles aufzulisten, was bereits existiert, um dieses Problem zu lösen — Tools, manuelle Workarounds, indirekte Konkurrenten. Wenn nichts existiert, ist das nicht unbedingt ein gutes Zeichen: Es kann bedeuten, dass der Markt zu klein ist oder das Problem nicht schmerzhaft genug.

Tag 4: Eine Landing Page in 4 Stunden bauen. Kein Custom-Code. Ein No-Code-Tool oder ein Template, ein Value Proposition in einem Satz, ein Anmeldeformular oder eine Warteliste. Ziel: eine URL zum Teilen haben.

Tag 5: Manuelle Distribution. Ich teile die Landing Page in 2 oder 3 Communities, in denen das Problem diskutiert wird. Kein Spam — eine Antwort auf einen bestehenden Thread, ein Post, der Mehrwert bietet, bevor das Tool erwähnt wird. Ich messe Klicks, Anmeldungen, direkte Antworten.

Meine Schwelle: Wenn bei ehrlicher Distribution innerhalb von 48 Stunden niemand klickt oder sich anmeldet, ist das Problem nicht schmerzhaft genug. Ich pivote oder breche ab — und das ist ein Erfolg, kein Scheitern. Ich habe 3 Wochen Entwicklung an etwas vermieden, das niemand wollte.

Wochen 2–3: Das MVP bauen — mit KI als Co-Entwickler

Nach der Validierung beginnt der Entwicklungssprint. Zwei Wochen, nicht drei. Wenn das MVP mehr als 14 Tage Code braucht, ist der Scope zu groß.

Die 3-Features-Regel

Ein Solo-MVP in 30 Tagen hat genau 3 Features. Nicht 5, nicht 7. Drei. Das, ohne das das Produkt nicht existiert. Das, das die Experience akzeptabel macht. Und das, das Lust auf mehr macht.

Alles andere wandert in eine backlog.md-Datei, die ich während des Sprints nicht öffne. Diese Disziplin ist die schwierigste — und die wichtigste.

Wie KI die Entwicklung konkret beschleunigt

Ich werde präzise sein, weil „KI hilft mir beim Coden” ohne Beispiele nichts aussagt.

Was KI in einem Solo-Sprint gut macht:

Boilerplate generieren — Authentifizierung, Rollenverwaltung, transaktionale E-Mails, Anbindung an eine Drittanbieter-API. Aufgaben, die früher einen ganzen Tag dauerten, fallen mit einem guten Prompt und ernsthafter Code-Review auf 2–3 Stunden.
Technische Sackgassen lösen — Wenn ich seit mehr als 30 Minuten an einem Bug feststecke, beschreibe ich den Kontext der KI. Sie schlägt 3 bis 5 Ansätze vor. Einer von fünf ist direkt nutzbar, die anderen lenken mein Denken. Das ist in 70 % der Fälle schneller als Stack Overflow.
Unit-Tests schreiben — Ich beschreibe das erwartete Verhalten, die KI generiert die Tests. Ich lese sie durch und korrigiere sie. Das dauert 20 Minuten statt 90.
Interne Dokumentation verfassen — README, Kommentare zu komplexen Funktionen, API-Dokumentation. Das an die KI zu delegieren spart mir 1 bis 2 Stunden pro Woche, ohne Qualitätseinbußen.

Was KI nicht gut macht:

Architekturentscheidungen. Wenn ich frage „Wie soll ich meine Datenbank für diesen Use Case strukturieren?”, bekomme ich eine generisch korrekte, aber nicht auf meine realen Constraints (Budget, erwartetes Volumen, bestehender Stack) zugeschnittene Antwort. Die Entscheidung treffe ich selbst.
Konsistenz über mehrere Sessions hinweg. KI erinnert sich nicht an den Kontext von gestern. Ich pflege eine context.md-Datei, die ich zu Beginn jeder Session einfüge, um nicht alles neu erklären zu müssen.
Das Erkennen subtiler Sicherheitslücken. Den gesamten Code rund um Authentifizierung und Zahlungen lese ich selbst durch — Zeile für Zeile.

Der reale Rhythmus der Wochen 2–3

Keine 14-Stunden-Tage. Blöcke von 4 bis 6 Stunden konzentrierter Entwicklung, am liebsten morgens. Abends: Review des tagsüber produzierten Codes, Update der backlog.md, Notizen zu Blockaden für den nächsten Tag.

In Woche 3 macht sich Entscheidungsmüdigkeit bemerkbar. Genau hier spielen die Kontext-Datei und die 3-Features-Regel ihre Rolle: Sie eliminieren zu treffende Entscheidungen und halten den Kurs. KI trägt die kognitive Last der repetitiven Aufgaben — ich bewahre meine Aufmerksamkeit für die Entscheidungen, die zählen.

Am Ende von Woche 3: ein funktionierendes Produkt, auf einer echten Domain deployed, zugänglich für die Personen, die sich in Woche 1 angemeldet haben. Nicht schön, nicht vollständig — aber funktional.

Woche 4: Launchen, verteilen, messen — die echten Ergebnisse

Woche 4 ist keine Entwicklungswoche. Es ist eine Distributionswoche. Wer in Woche 4 weiter coded, schiebt den Moment der Wahrheit hinaus.

Was „launchen” solo konkret bedeutet

Ein Solo-Launch ist kein Product-Hunt-Launch mit 500 Upvotes am Tag X. Es ist eine schrittweise Bereitstellung, Kanal für Kanal, mit Messung bei jedem Schritt.

Tag 22–23: Aktivierung der Angemeldeten aus Woche 1. Die Personen, die ihre E-Mail-Adresse hinterlassen haben, erhalten Zugang. Keine Marketing-E-Mail — eine persönliche (oder quasi-persönliche, leicht personalisierte) Nachricht, die erklärt, was sie vorfinden werden, und um direktes Feedback bittet. Die Antwortrate bei solchen Nachrichten übersteigt 30 %, wenn die Liste klein und qualifiziert ist.

Tag 24–25: Ein ausführlicher Post auf einem Kanal. Kein generischer Twitter/X-Thread. Ein Post, der das Problem, die Lösung und die ersten Rückmeldungen beschreibt — mit echten Zahlen. Maker- und Indie-Hacker-Communities reagieren gut auf dieses Format, sofern es ehrlich und nicht werblich ist.

Tag 26–28: Messen und schnell iterieren. Ich schaue auf drei Metriken: Anzahl aktiver Nutzer (die die Hauptaktion mindestens einmal ausgeführt haben), Retentionsrate an Tag +3 (kommen sie wieder?) und direkte qualitative Rückmeldungen (was blockiert?).

Tag 29–30: Entscheidung. Weitermachen, pivoten oder stoppen. Diese Entscheidung wird auf Basis von Daten getroffen, nicht von Emotionen.

Die echten Ergebnisse eines 30-Tage-Sprints

Ich bin ehrlich darüber, was man realistischerweise erwarten kann:

Ein funktionierendes, deployedes Produkt mit echten Nutzern: Ja, das ist erreichbar.
Signifikante wiederkehrende Einnahmen nach 30 Tagen: Nein, außer in Ausnahmefällen. Distribution braucht Zeit. Die ersten Einnahmen kommen in der Regel zwischen Tag 30 und Tag 90, wenn die initiale Validierung solide war.
Ein perfektes Produkt: Nie. Und das ist das Ziel. Ein unvollkommenes Produkt, das genutzt wird, ist unendlich mehr wert als ein perfektes Produkt, das noch nicht existiert.

Was der 30-Tage-Sprint wirklich produziert, ist eine echte Feedback-Schleife. Du weißt, ob du ein reales Problem löst. Du hast Daten, um zu entscheiden, was du als Nächstes baust. Das ist der Wert — nicht der Umsatz von Monat 1.

Für weiterführende Zahlen rund um die Ökonomie des Solopreneurs und was KI konkret an der Gleichung ändert, habe ich seriöse Quellen in unserem Dossier statistiques solopreneur & IA 2026 zusammengestellt.

Was ich anders machen würde — und die zentrale Lektion

Nach mehreren Zyklen dieser Art von Sprint sind hier die Fehler, die ich seltener wiederhole — und die ich bei anderen Makern systematisch sehe.

Wiederkehrende Fehler

Zu früh anfangen zu coden. Das ist Fehler Nummer eins. Code vermittelt das Gefühl von Fortschritt. Validierung liefert echte Information. Das ist nicht dasselbe.

Distribution unterschätzen. Ein Produkt ohne Distribution existiert nicht. Solo hast du kein Marketing-Team — also baust du entweder vor dem Launch eine Audience auf, oder du stützt dich auf bestehende Communities. Eine dritte Option gibt es nicht. Wenn dich das Thema Distribution interessiert, kann das Audit deiner Website Sichtbarkeitsprobleme aufdecken, die du noch nicht identifiziert hattest.

Mehrere Ideen parallel validieren wollen. In einem 30-Tage-Solo-Sprint: eine Idee auf einmal. Verzetteln tötet kurze Sprints.

Entscheidungsmüdigkeit ignorieren. Nach 15 Tagen intensiver Entwicklung sinkt die Qualität der Entscheidungen. Systeme einzurichten (3-Features-Regel, Kontext-Datei, geschlossenes Backlog) ist keine Frage der Organisation — es ist eine Frage des kognitiven Überlebens.

Die zentrale Lektion

Die Kosten, ein digitales Produkt zu bauen, sind eingebrochen. KI hat das real gemacht, nicht nur theoretisch. Ein Solo-Dev im Jahr 2026 produziert in bestimmten Dimensionen das, was ein kleines Team 2019 produziert hat.

Aber die Kosten dafür, zu entscheiden, was für wen gebaut wird, sind keinen Cent gesunken. Genau da spielt sich das Wesentliche ab. KI kann Code generieren, E-Mails verfassen, Bugs lösen — sie kann nicht entscheiden, ob deine Idee es wert ist, gebaut zu werden. Das ist dein Job.

Der 30-Tage-Sprint ist ein Entscheidungswerkzeug, das als Entwicklungswerkzeug verkleidet ist. Seine eigentliche Aufgabe: dich zwingen, deine Idee mit der Realität zu konfrontieren, bevor du Monate darin investierst.

Wenn du während eines solchen Sprints an einem technischen Aspekt feststeckst — ein hartnäckiger Bug, eine Integration, die nicht funktioniert — dafür gibt es Unstuck: technische Entsperrung auf Abruf, ohne langfristige Bindung.

Dreißig Tage sind kurz. Kurz genug, um den Schwung zu halten, lang genug, um eine echte Feedback-Schleife zu haben. Das ist das Format, das am besten zur Realität eines Solo-Studios passt: kein unendlicher Runway, kein Team, das Fehler auffängt — aber die Fähigkeit, schnell zu shippen und schnell zu lernen, die schwerere Strukturen nicht haben.

Ship · Earn · Keep.

Sébastien de Bollivier ist seit 2008 Freelance-Dev und baut seit La Réunion aus solo Produkte. Wer einen Dev sucht, um ein Projekt zu beschleunigen oder eine Architektur zu validieren, findet sein Profil auf sebastiendebollivier.com.

Häufige Fragen

Ist es wirklich möglich, ein digitales Produkt solo in 30 Tagen zu bauen?

Ja — vorausgesetzt, du definierst einen sehr engen MVP-Scope (maximal 3 Features) und validierst die Idee, bevor du auch nur eine Zeile Code schreibst. KI reduziert die Entwicklungszeit bei repetitiven Aufgaben um 40 bis 60 %, aber die Entscheidung, was gebaut wird, bleibt vollständig beim Menschen.

Welchen Tech-Stack wählen, um solo schnell voranzukommen?

Nimm einen Stack, den du bereits zu 80 % beherrschst. Während eines 30-Tage-Sprints die Sprache oder das Framework zu wechseln ist der sicherste Weg, nicht fertig zu werden. KI kann die restlichen 20 % auffüllen — einen unpassenden Stack-Entscheid kann sie nicht reparieren.

Wie verteilt man ein Solo-Produkt ohne bestehende Audience?

Fang mit einem einzigen Kanal an: einer gezielten Community (Discord, Forum, Subreddit), in der dein Problem bereits diskutiert wird. In Woche 4 eines Solo-Sprints mehrere Kanäle gleichzeitig bespielen heißt, sich zu verzetteln. Ein gut bearbeiteter Kanal schlägt fünf oberflächlich bespielte.

Eine Idee zum Shippen? Eine Website, ein SaaS, eine KI-Automatisierung – gemeinsam mit dir gebaut.

Über dein Projekt sprechen