Ein Produkt pro Monat: die Methode des Solo-Studios (und warum sie funktioniert)

Kurz gesagt — Ein Produkt pro Monat solo zu launchen ist machbar — unter einer Bedingung: nie wieder bei null anfangen. Die wiederverwendbare Infrastruktur (Auth, Zahlung, Deployment, Content) ist das, was aus einem erschöpfenden Tempo ein System macht.

---

Das erste Produkt, das ich gelauncht habe, hat mich sechs Wochen gekostet. Das letzte: vierundzwanzig Stunden zwischen dem Kauf der Domain und der Live-Site mit funktionierender Zahlung. Nicht weil ich schneller gearbeitet habe — sondern weil ich fast nichts neu gebaut habe.

Ein Produkt pro Monat launchen klingt nach Hustle-Porn. Ist es nicht. Es ist Ingenieursdisziplin, angewandt auf Produkte: erkennen, was sich wiederholt, es abstrahieren, es wiederverwenden. Der Rest — die Idee, das Positioning, die Distribution — das ist, wo menschliche Energie hingehört. Nicht ins Verkabeln.

Das habe ich gelernt, während ich das Studio SEK aufgebaut habe. Alleine. Von La Réunion aus. Mit Familie und einem engen Kalender.

Warum Shipping-Geschwindigkeit Perfektion schlägt

Die direkte Antwort: weil der Markt dir Informationen liefert, die dein Kopf allein nicht produzieren kann.

Ein nicht gelaunches Produkt ist eine Hypothese. Ein gelaunches Produkt — auch unfertig, auch ohne Traffic — ist ein Experiment. Der Unterschied: echtes Signal gegen internen Lärm.

Das Problem mit Perfektion: sie ist von außen unsichtbar. Nutzer sehen nicht, was du drei Wochen lang poliert hast. Sie sehen, ob das Produkt ihr Problem in unter dreißig Sekunden löst. Wenn nicht, sind sie weg. Die wahrgenommene Qualität beim ersten Kontakt hängt von der Klarheit der Botschaft ab — nicht von der Sauberkeit des Codes.

Es gibt ein zweites, brutaleres Argument: Opportunitätskosten. Jede Woche, die du mit Polieren verbringst, ist eine Woche ohne Feedback, ohne SEO, das anfängt sich zu indexieren, ohne ersten Kunden, der dir sagt, was nicht stimmt. In einem Solo-Studio ist Zeit die knappste Ressource. Sie auf mehrere Wetten zu verteilen reduziert das Gesamtrisiko — genau wie ein diversifiziertes Portfolio.

Das bedeutet nicht, Mist zu shippen. Es bedeutet, einen ehrlichen Minimalumfang zu definieren — was das Produkt wirklich tut, was es noch nicht tut — und daran festzuhalten. Ein Produkt, das eine Sache gut macht, ist mehr wert als eines, das zehn verspricht und sechs halb liefert.

Der Rhythmus von einem Produkt pro Monat erzwingt diese Disziplin. Kein Zeit für Scope Creep. Keine Zeit, die UI dreimal neu zu bauen. Zeit, das Problem zu definieren, die minimale Lösung zu bauen, sie online zu stellen und weiterzumachen. Am Anfang unbequem. Mit der Zeit befreiend.

Wie wiederverwendbare Infrastruktur den Rhythmus möglich macht

Wiederverwendbare Infrastruktur ist das, was aus einem erschöpfenden Tempo ein System macht. Ohne sie ist ein Produkt pro Monat reiner Dauersprint. Mit ihr ist es Komposition.

Hier sind die vier Blöcke, die ich über die SEK-Launches hinweg standardisiert habe:

1. Auth und Account-Management. Wenn du zum ersten Mal eine Authentifizierung verkabelst — E-Mail/Passwort, OAuth, Session-Management, Passwort-Reset — kostet das locker einen Tag. Beim zweiten Mal kopierst du das Modul. Beim fünften Mal installierst du es in zwanzig Minuten. Ich nutze denselben Stack (Next.js + Supabase Auth) für alle Produkte, die einen Account brauchen. Der Code ist zu 90 % identisch. Nur die Business-Logik ändert sich.

2. Zahlung. Stripe wird einmal verkabelt, einmal getestet, einmal dokumentiert. Checkout, Webhooks, Abo-Verwaltung, Kundenportal — alles steckt in einem Modul, das ich importiere. Aufwand für ein neues bezahltes Produkt: unter einer Stunde. Ohne das fängt jeder Launch denselben Schmerz von vorne an.

3. Deployment. Vercel plus ein standardisiertes Deployment-Skript. Jedes Produkt hat dieselbe Pipeline: Push auf main → Build → Live. Keine manuelle Konfiguration, keine Überraschungen. DNS wird über einen einzigen Provider mit Record-Templates verwaltet. Eine Domain kaufen und eine Live-Site haben dauert unter dreißig Minuten, wenn man das zehnmal gemacht hat.

4. Automatisierter Content. Basis-SEO-Seiten (Landing, FAQ, Blog), transaktionale E-Mails, Open-Graph-Metadaten — alles wird aus Templates generiert. KI kommt hier konkret ins Spiel: Ich generiere den ersten Entwurf des Landing-Textes in wenigen Minuten, überarbeite ihn, veröffentliche. Kein Wunder — aber es beseitigt die Blockade der leeren Seite bei strukturierten Inhalten.

Was diese Infrastruktur nicht tut: Sie ersetzt nicht das Nachdenken über Positioning, die Wahl der Zielgruppe, die Entscheidung, ob man launcht oder nicht. Das ist menschliches Urteilsvermögen — kein Template kann das ersetzen.

Das Ergebnis in Zahlen: Das erste SEK-Produkt hat mich von Anfang bis Ende rund sechs Wochen gekostet. Das vierte: zehn Tage. Das letzte: vierundzwanzig Stunden bis zu etwas Livem und Vorzeigbarem. Die Lernkurve ist real — und sie ist steil im richtigen Sinne.

Von der Domain-Registrierung zur Live-Site in 24 Stunden: wie das konkret abläuft

Hier ist der echte Ablauf des letzten Launches — ohne Schönfärberei.

Stunde 0 — Die Idee und die Domain. Die Idee kommt aus einem Problem, das ich selbst hatte, oder aus einer eingehenden Anfrage. Ich prüfe in zehn Minuten: Ist die Domain verfügbar? Macht das schon jemand anderes (kurze Suche)? Ist das Problem schmerzhaft genug, damit jemand zahlt? Wenn alle drei Antworten positiv sind, kaufe ich die Domain. Kosten: unter 15 €. Risiko: minimal.

Stunde 1 bis 3 — Die Landing-Page. Ich starte mit einem Next.js-Template, das ich schon habe. Ich ändere Name, Problem, Value Proposition, Farben. Die KI generiert den ersten Textentwurf der Landing-Page (Headline, Untertitel, drei Benefits, FAQ). Ich lese Korrektur, streiche das Generische, füge das Spezifische zum Problem hinzu. Das Ergebnis ist nicht perfekt — es ist ehrlich.

Stunde 3 bis 6 — Zahlung und minimale Business-Logik. Ich importiere das Stripe-Modul, konfiguriere ein Produkt im Stripe-Dashboard (Preis, Beschreibung, Zahlungsart). Ich verkable den Webhook, um die Bestätigungs-E-Mail auszulösen. Die Business-Logik des Produkts selbst — was es konkret tut — ist entweder eine geschützte Seite oder ein einfacher Flow. Ich baue nicht alles. Ich baue, was die erste Zahlung rechtfertigt.

Stunde 6 bis 12 — Deployment und DNS. Push auf main, Vercel deployed automatisch. Ich konfiguriere die Custom-Domain, zeige die DNS-Einträge. Propagation: in der Regel 15 bis 30 Minuten. Ich teste den kompletten Funnel: Landing → Checkout → Bestätigungs-E-Mail → Produktzugang. Wenn das klappt, ist es live.

Stunde 12 bis 24 — Erste Distribution. Ich poste auf den Kanälen, auf denen ich schon präsent bin. Keine Kampagne, kein Werbebudget. Nur: Das habe ich gebaut, das ist das Problem, das es löst, hier ist der Link. Erste Rückmeldungen kommen innerhalb von 24 bis 48 Stunden. Manchmal nichts. Manchmal ein erster Kauf. Manchmal ein Feedback, das die Richtung des Produkts verändert.

Was diesen Rhythmus möglich macht: Ich entdecke bei jedem Launch nichts Neues. Jeder Schritt ist bekannt, dokumentiert, mit Werkzeugen ausgestattet. Das Unbekannte ist ausschließlich das Problem und die Zielgruppe — und genau dort sollte die Energie hinfließen.

Was man nie zweimal macht

Die Regel ist einfach: Wenn du etwas zweimal tust, dokumentierst du es. Wenn du es dreimal tust, automatisierst du es oder abstrahierst es in ein Modul.

Hier ist die konkrete Liste dessen, was ich im Studio SEK nie mehr von Grund auf neu baue:

• Die Next.js-Projektstruktur (Routing, Layout, Basiskomponenten, Dark Mode, Responsive)
• Das Auth-Modul (Supabase Auth, Route-Protection-Middleware)
• Das Zahlungsmodul (Stripe Checkout, Webhooks, Kundenportal)
• Die Deployment-Pipeline (Vercel, Umgebungsvariablen, Preview Deployments)
• Transaktionale E-Mails (Bestätigung, Willkommen, Follow-up) — Resend-Templates
• Basis-SEO-Konfiguration (Metadaten, Sitemap, robots.txt, Open Graph)
• Das Skript für Domain-Kauf und DNS-Konfiguration
• Die Launch-Checkliste (15 Punkte, von der Landing-Page bis zum ersten Distribution-Post)

Jedes dieser Elemente wurde beim ersten Mal mit etwas Schmerz gebaut. Beim zweiten Mal dokumentiert. Danach reibungslos wiederverwendet.

KI spielt hier eine Rolle — aber eine präzise: Sie beschleunigt die Generierung von strukturiertem Content (Landing-Texte, E-Mails, FAQs, Produktbeschreibungen) und hilft beim schnellen Debuggen. Sie ersetzt nicht die Entscheidung, was man baut, und auch nicht das Urteil darüber, was an einem Produkt gut oder schlecht ist. Diese beiden Dinge bleiben menschlich — und das sollten sie auch bleiben.

Wenn du tiefer in den echten Einfluss von KI auf das Solo-Produktionstempo einsteigen willst, findest du die Zahlen in unserem Dossier Statistiken Solopreneur & KI 2026.

Die Moratorium-Regel: wann man aufhört zu launchen

Ein Produkt pro Monat zu launchen ist kein Selbstzweck. Es ist ein Entdeckungswerkzeug. Irgendwann muss Entdeckung der Verwertung weichen — sonst häuft man verwaiste Projekte an, die nie wachsen.

Das Moratorium ist die bewusste Entscheidung, für einen definierten Zeitraum keine neuen Produkte zu launchen, um einem bestehenden Produkt die Aufmerksamkeit zu geben, die es verdient.

Die Signale, die bei mir ein Moratorium auslösen:

1. Ein Produkt beginnt, regelmäßigen organischen Traffic zu generieren. SEO braucht Zeit — aber wenn es anspringt, verdient es Pflege: neue Inhalte, Verbesserung bestehender Seiten, interne Verlinkung. Das lässt sich nicht parallel zu einem neuen Launch betreiben.

2. Eingehende Anfragen kommen, ohne dass ich sie angestoßen habe. Das ist das stärkste Signal. Jemand hat das Produkt selbst gefunden, die Value Proposition verstanden und will mehr. Das zu ignorieren, um ein neues Produkt zu launchen, ist ein Prioritätsfehler.

3. Wiederkehrende Einnahmen überschreiten eine Schwelle, die Investitionen rechtfertigt. Sobald ein Produkt genug generiert, um seine Wartungskosten mit Marge zu decken, verdient es eine ernsthafte Roadmap statt zerstreuter Aufmerksamkeit.

4. Technische Schulden beginnen, Verbesserungen zu bremsen. Wenn jede Änderung doppelt so lange dauert wie sie sollte, weil der Code des schnellen Launches nie refaktoriert wurde, ist es Zeit, innezuhalten und zu konsolidieren.

Das Moratorium ist kein Scheitern des Rhythmus. Es ist der Rhythmus, der funktioniert: Du hast schnell genug gelauncht, um zu finden, was es wert ist, entwickelt zu werden. Jetzt entwickelst du es.

Die Dauer, die ich nutze: ein Moratorium von vier bis acht Wochen, in denen keine neue Domain gekauft und keine neue Idee prototypisiert wird. Die gesamte Energie fließt in das Produkt mit Traktion. Nach dem Moratorium wird neu bewertet.

---

Die Produkte des Studios SEK werden nach dieser Methode gebaut — wiederverwendbare Infrastruktur, schnelle Launches, Moratorien wenn das Signal es verlangt. Du kannst einige davon direkt ansehen: /codeavecpapa/ zum gemeinsamen Coden von Elternteil und Teenager mit KI, /audit/ für eine vollständige Diagnose deiner Website, /unstuck/ um ein technisches Problem express zu lösen.

Wenn du solo baust und schneller vorankommen willst, ohne dich zu verbrennen, geht das Gespräch weiter auf sebastiendebollivier.com.

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

Über dein Projekt sprechen