Minimales Geschäftssystem für Solo-Founder: Website, Produkt, Zahlung, Daten und Automatisierung

Öffne launch-checklist.md: Die Seite /pricing existiert, aber das Stripe Product fehlt. Der Login funktioniert, doch der Abo-Status wird nicht synchronisiert. GA4 erhält page_view, aber der Klick auf den Zahlungsbutton löst kein Event aus. Das Feedbackformular sendet eine E-Mail, ohne eine Aufgabe anzulegen.

Viele Indie-Entwickler behandeln „es läuft“ als Startkriterium. Die Lücken werden sichtbar, wenn ein zahlender Kunde noch manuell freigeschaltet wird oder ein kostenloses Kontingent überschritten ist, bevor jemand die Nutzung geprüft hat.

Ein minimales Geschäftssystem für Solo-Founder ist nicht wegen weniger Tools tragfähig. Seine Geschäftsaktionen müssen vollständig durchlaufen: Nutzer kommen an, erhalten das Produkt, zahlen, bekommen Zugriff, erzeugen auswertbare Daten, senden Feedback und erreichen im Fehlerfall eine zuständige Person.

Mit der ersten Tabelle findest du die unterbrochene Übergabe. Danach lässt sich entscheiden, welche Ebenen eine Minimalversion benötigen und was warten kann.

Abnahmetabelle: Diese Schnittstellen müssen vor dem Start schließen

Der Abnahmestandard lautet nicht „alle Funktionen sind vorhanden“. Jede Geschäftsaktion muss vom Auslöser bis zum Ergebnis funktionieren. Stripe Webhook, Supabase RLS und GA4 Events landen oft erst am Abend vor dem Start im Projekt, weil zuvor nur geprüft wurde, ob die Seite rendert.

Diese Schnittstellen sollten vor dem Start praktisch getestet werden:

Bereich	Zu schließende Schnittstelle	Häufige Lücke	Abnahmeaktion
Website-Einstieg	Seiten laden, Routen liefern keine 404, Assets laden, Build-Verbrauch wird überwacht	Cloudflare-Free-Builds sind aufgebraucht; niemand liest Fehlerprotokolle	Start- und Preisseite auf einem echten Gerät öffnen; Build-Verlauf in Cloudflare Pages prüfen
Produktform	Content-Site/Tool/SaaS ist klar, die Preisseite zeigt ein Angebot	Nur Beschreibung, aber kein Preis oder Kaufweg; Stripe Product fehlt	Products/Prices im Stripe Dashboard prüfen; Anzeige unter /pricing kontrollieren
Vollständige Zahlung	Checkout Session, Webhook, Freischaltung, Fehler/Abbruch und Abo-Sync funktionieren	Kein Webhook; Zahlung ohne Zugriff; Rückerstattung ohne Statusänderung	Mit einer Stripe-Testmethode zahlen; Webhook-Logs und Abo-Tabelle prüfen
Nutzersystem	Login, RLS, Abo-Sync und unterschiedliche freie/bezahlte Rechte funktionieren	Login ohne RLS; alle Nutzer sehen bezahlte Inhalte	Nach Login subscriptions prüfen; RLS mit einem kostenlosen Konto testen
Daten-Events	GA4/GSC, 5–8 Geschäfts-Events, Zahlung/Registrierung/Test und Fehlerwarnung funktionieren	GA4 kennt nur page_view; Zahlungsklick und Registrierung fehlen	Sammlung in GA4 DebugView prüfen; Queries und Seiten im GSC Performance report ansehen
Feedback-Schleife	Feedback wird gesendet, in Arbeit überführt und beantwortet	Nur E-Mail, aber kein Aufgabenboard oder Bearbeitungsstatus	Feedback absenden und Eingang im Board oder Postfach prüfen
Automatisierungsgrenze	Webhook/API/Cron haben Verbrauchsgrenze, Warnung und Rollback	Fehler bleiben still; die Grenze fällt erst nach Überschreitung auf	Workers-Verbrauch prüfen; Grenzwert und Fehlermonitoring einrichten
Kostenkontrolle	Cloudflare/Supabase-Verbrauch wird erfasst, Free-Grenzen und Upgrade-Auslöser sind bekannt	Ein inaktives Supabase-Free-Projekt pausiert; Workers-Grenze bleibt unbemerkt	Cloudflare-Verbrauch und Supabase-Aktivität prüfen; Upgrade-Auslöser dokumentieren

Jede Zeile verlangt eine echte Aktion, nicht nur die Kontrolle einer Konfigurationsdatei. Vor dem Start sollten mindestens eine vollständige Zahlung, ein Login- und Rechtetest, eine Event-Prüfung und eine Feedback-Einsendung abgeschlossen sein.

Website-Einstieg: minimaler Deployment-Stack und Grenzen

Die Website ist die erste Ebene. Eine statische Site oder ein leichtes Framework ist ein guter Anfang, doch Build-Anzahl, Dateizahl und dynamische Funktionen gehören in die Kostenübersicht. Cloudflare Pages und Astro senken den Wartungsdruck; ihre kostenlosen Kontingente sind trotzdem keine Architekturgarantie.

Tabelle zur Stack-Auswahl

Produktform	Empfohlener Stack	Build-Kosten	Kosten dynamischer Funktionen	Geeignete Nutzung
Content-Site	Astro / Hugo / Hexo	Cloudflare Pages Free: 500 builds/month, 20.000 files, 25 MiB asset	Pages Functions zählen zu Workers	Blog, Dokumentation, SEO-Seiten, Produktseiten
Tool-Site	Astro + API-Aufrufe	Wie oben	API-Aufrufe zählen zu Workers (100.000 requests/day)	Einzelseiten-Tools, Abfragen, Rechner, Visualisierung
SaaS	Astro + Supabase	Wie oben	Workers + Supabase Edge Functions	Mehrere Nutzer, Abos, Rechte, Datenbankzugriffe

Am 26. Juli 2026 nennen die offiziellen Cloudflare-Pages-Limits für Free weiterhin 500 Builds pro Monat, 20 Minuten Build-Timeout, höchstens 20.000 Dateien und 25 MiB pro Asset. Pages Functions verbrauchen Workers-Kontingente; Workers Free enthält 100.000 Anfragen pro Tag und 10 ms CPU pro Aufruf.

Kostenlose statische Asset-Anfragen machen nicht das ganze System kostenlos. Bei vielen Bildern, Videos oder Downloads zählen zusätzlich Objektspeicher, CDN-Verarbeitung, Transformation und Egress.

KI-generierte Seiten brauchen eigenen Nutzwert

Die Google-Search-Hinweise zu generativer KI erlauben KI-Unterstützung bei Recherche und Struktur. Viele Seiten ohne zusätzlichen Nutzwert können jedoch gegen die Richtlinie zu scaled content abuse verstoßen. Ein Einstieg braucht ein echtes Produkt, echtes Feedback und reale Auswertung statt Hunderter automatisch erzeugter SEO-Seiten.

Für die Performance einer Content-Site hilft der Astro-5-Praxisartikel. Ein minimales System braucht vor dem Start keinen Lighthouse-Wert von 100, aber funktionierende Seiten, Assets und CTAs sowie sichtbare Build-Fehler.

Produktebene: Content-Site, Tool oder SaaS als erste Version?

Die Produktform bestimmt die Komplexität von Zahlung, Nutzern, Daten und Automatisierung. Content-Site, Tool und SaaS sind keine gleichwertigen Knöpfe, sondern steigende betriebliche Verpflichtungen. Die erste Version sollte die vertrauteste Technik, das einfachste Zahlungsmodell und möglichst wenig Nutzerdaten bevorzugen.

Entscheidungstabelle zur Produktform

Produktform	Stack-Komplexität	Zahlungskomplexität	Nutzerdatenbedarf	Eignung für die erste Version
Content-Site	Niedrig: statisch + CMS + SEO	Niedrig: Einmalkauf oder kostenlos	Niedrig: E-Mail, RSS, Kommentare	Hoch: SEO-Akquise, Content-Umsatz, Nachfrageprüfung
Tool-Site	Mittel: statisch + API + leichtes Backend	Mittel: Einmalkauf oder Abo	Mittel: leichtes Nutzersystem, Verlauf	Mittel: Validierung einer Kernfunktion und eines Preismodells
SaaS	Hoch: Auth + Datenbank + Abo + RLS	Hoch: Abo, Nutzung, Rückerstattung	Hoch: mehrere Nutzer, Rechte, Abo-Status, Datentrennung	Niedrig: bei klarer Zahlungsnachfrage und vertrautem Stack

Entscheidungskriterien

Drei Faktoren bestimmen die erste Form:

1. Stack-Erfahrung: Wer Astro oder Hugo kennt, kann mit Content schnell Nachfrage prüfen. Erfahrung mit Supabase oder Postgres senkt das Risiko eines Tools oder SaaS.
2. Zahlungskomplexität: Einmalkauf ist meist einfacher als Abo, Abo einfacher als nutzungsbasierte Abrechnung. Beginne mit Einmalkauf oder kostenlosem Lead und ergänze komplexe Abrechnung bei echtem Bedarf.
3. Nutzerdaten: Content braucht vielleicht nur E-Mail und RSS; ein Tool benötigt Verlauf; SaaS braucht Identität, Rechte, Abo-Status und Datentrennung.

Die Produktform ist keine Identität. Solange eine Kernaktion unzuverlässig ist, sollten Kontocenter, Teamräume und Vorlagenmarkt nicht zuerst entstehen.

Zahlungsebene: kein letzter Button, sondern Eingabe für das Datenmodell

Zahlungen sind die risikoreichste Ebene des Minimalsystems. Sie beeinflussen Datenbank, Nutzer, Berechtigungen, Admin-Oberfläche und Benachrichtigungen. Wenn Checkout kassiert, der Webhook aber keinen Zugriff gewährt, Rückerstattungen den Status nicht ändern oder abgelaufene Abos Rechte behalten, ist die Leistung nicht erfüllt.

Checkliste für den Zahlungsablauf

Ein minimaler Stripe-Ablauf enthält diese Schritte:

Schritt	Stripe-Objekt	Zu schließende Schnittstelle	Häufige Lücke
1. Produkt anlegen	Products	Produkt im Stripe Dashboard anlegen und Preis anzeigen	Preis unter /pricing, aber kein Stripe Product
2. Preis anlegen	Prices	Betrag, Währung, Zeitraum und Einmal/Abo/Nutzung konfigurieren	Kein interval beim Abo; kein meter bei Nutzung
3. Checkout Session anlegen	Checkout Session	line_items, mode, success_url, cancel_url setzen	success_url leitet nur weiter und prüft den Status nicht
4. Webhook konfigurieren	Webhook endpoint	checkout.session.completed, invoice.paid, customer.subscription.deleted und ähnliche Events empfangen	Kein Webhook; Zahlung schaltet nichts frei
5. Auftrag erfüllen	Eigene Logik	Zugriff in der Datenbank gewähren und Bestätigung senden	Nicht nachvollziehbare Handarbeit
6. Rückerstattung behandeln	Refunds	Status ändern, Zugriff entziehen und Nutzer benachrichtigen	Bezahlter Zugriff bleibt nach Rückerstattung
7. Abo-Status synchronisieren	Subscriptions	Status nach Verlängerung, Kündigung oder Ablauf aktualisieren	Rechte bleiben nach Ablauf bestehen

Entscheidungstabelle zum Zahlungsmodell

Das Zahlungsmodell verändert das Datenmodell:

Zahlungsmodell	Auswirkung auf Daten	Rechteverwaltung	Geeignete Nutzung
Einmalzahlung	paid_at oder purchase_id am Nutzer oder Kaufdatensatz	Einmal dauerhaft oder befristet gewähren	Digitale Produkte, Kurse, Vorlagen, Einzelkauf-Tools
Abo	subscriptions mit user_id, stripe_subscription_id, status, current_period_end	Periodisch gewähren und entziehen; Sync nötig	Tools, SaaS, Mitgliederinhalte
Nutzungsabrechnung	usage mit user_id, meter, amount, timestamp	Nutzung und Kontingent begrenzen; Guthabentabelle nötig	APIs, Cloud-Speicher, Rechenleistungen

Mit Stripe Products und Prices lässt sich ein neuer Price anlegen und ein lookup key auf ihn übertragen. Die Abfrage per Schlüssel vermeidet fest codierte Price IDs an mehreren Stellen, doch Preisänderungen brauchen weiterhin den offiziellen Anlage- und Aktivierungsablauf.

Fulfillment, Rückerstattung und Abo-Status gehören in Webhook- und Datenbanklogik. Eine Success-Seite oder manuelle Dashboard-Arbeit reicht nicht. Eine ausführliche Auswahl bietet der Vergleich der Zahlungssysteme für Solo-Founder.

Testzahlung verifizieren

Vor dem Start muss ein vollständiger Ablauf in der Stripe-Testumgebung durchlaufen:

1. Testumgebung im Stripe Dashboard verwenden
2. Aktuell dokumentierte Testmethoden für Erfolg, Fehler und zusätzliche Authentifizierung nutzen
3. Checkout mit den Testdaten abschließen
4. Payments und Events prüfen und das erwartete Event bestätigen
5. subscriptions oder Berechtigungsdatensatz auf synchronisierten Status prüfen
6. Zugriff nach Login testen und mit einem unberechtigten Konto wiederholen

Danach werden Produktionsschlüssel, Webhook endpoint, Event-Signaturen und Benachrichtigungen separat geprüft.

Nutzerebene: Identität, Rechte und Abo-Status unterscheiden

Ein Nutzersystem ist mehr als ein Login-Button. Die Minimalversion unterscheidet Identität, Rechte, Abo-Status und Datenzugriffsgrenzen. Wenn der Login klappt, aber jeder bezahlte Daten lesen kann, liegt das Problem in der Autorisierung.

Supabase Auth kann Passwort, magic link, OTP, soziale Anmeldung und SSO behandeln. Für die Autorisierung arbeiten JWT und Datenbank-RLS zusammen. Authentifizierung beantwortet „Wer bist du?“, eine RLS policy entscheidet, welche Zeilen gelesen oder geschrieben werden dürfen.

Checkliste für das minimale Nutzersystem

Nutzerfähigkeit	Supabase-Funktion	Zu schließende Schnittstelle	Häufige Lücke
Authentifizierung	Passwort, magic link, OTP, soziale Anmeldung, SSO	Nutzer meldet sich an, erhält JWT und greift auf eigene Daten zu	Login ohne Autorisierung
Rechteverwaltung	RLS (Row Level Security)	Nutzer sehen eigene Daten; bezahlte Nutzer erhalten bezahlten Inhalt	RLS aus oder policy zu weit
Abo-Sync	Stripe webhook → subscriptions	Status nach Zahlung, Verlängerung, Kündigung und Ablauf ändern	Status bleibt nur in Stripe
Datengrenze	RLS policy	Nutzer sehen eigene Zeilen; Adminpfade haben separate Rechte	Keine Isolation; fremde Daten sind sichtbar

Ein Supabase-Projekt basiert auf Postgres; Auth, Storage, Realtime und Edge Functions arbeiten darum. Ein vertrauenswürdiges Backend aktualisiert den Abo-Status. Der Browser darf nicht entscheiden, ob bezahlter Zugriff besteht.

Vor dem Start wird RLS mit mindestens zwei Konten geprüft: eines mit, eines ohne Berechtigung. Außerdem dürfen service role und andere hochprivilegierte Schlüssel nicht im Browser erscheinen.

Datenebene: 5–8 Geschäfts-Events statt eines Statistikskripts

Eine GA4-Installation ist noch keine Datenebene. Die Minimalversion braucht nur 5–8 entscheidungsrelevante Events, sollte aber Besuch, Klick, Kernaktion, Registrierung, Zahlung, Fehler und Feedback abdecken.

Tabelle der Geschäfts-Events

Geschäfts-Event	GA4-Eventname	Auslöser	Zweck der Auswertung
Seitenaufruf	page_view	Seite lädt	Einstiegs- und SEO-Akquise
Zahlungsbutton	begin_checkout oder eigenes Event	Kauf oder Abo wird geklickt	Funnel und Preisseite
Registrierung	sign_up	Registrierung abgeschlossen	Konversion und Akquisequalität
Teststart	Eigenes trial_start	Test oder kostenlose Nutzung beginnt	Testkonversion und Erfahrung
Zahlungsabschluss	purchase	Backend bestätigt Erfolg	Umsatz und Zahlungsablauf
Fehler	Eigenes error_occurred	Frontend-, API- oder Kernaktionsfehler	Stabilität und Priorisierung
Feedback	Eigenes feedback_submit	Nutzer sendet Rückmeldung	Feedbackrate und Klassifizierung

GA4 kann geschäftskritische Aktionen als key event markieren. Realtime und DebugView prüfen die Sammlung; für die Produktion zählen außerdem Parameter, Attribution und Deduplizierung.

Routine zur Datenauswertung

Mindestens wöchentlich wird geprüft:

1. GA4: Geschäfts-Events ansehen: Sammlung in DebugView bestätigen und den Weg von Besuch über Registrierung und Test bis zur Zahlung auswerten.
2. GSC: Queries und Seiten ansehen: Klicks, Impressionen, CTR, durchschnittliche Position, Queries und Seiten statt nur Gesamttraffic prüfen.
3. Produktanalyse: Detailbedarf bestimmen: PostHog oder Ähnliches ergänzen, wenn GA4 nicht zeigt, was ein bestimmter Nutzer wie oft getan hat oder wo er ausgestiegen ist.

GSC, Logs und Fehlerwarnungen sind vor Umsatz wichtig. Sie zeigen Suchanfragen, Reibung auf der Preisseite, gescheiterte Kernaktionen und häufige Fehler. Beginnt die Erfassung erst beim ersten zahlenden Kunden, sind frühere Ursachen verschwunden.

Automatisierungsebene: Was am ersten Tag hilft und was Risiko erhöht

Einige Automatisierungen entfernen sichere Wiederholung, andere vergrößern Schäden bei Fehlern. KI-Coding-Tools beschleunigen Entwicklung, können aber Zahlungsabwicklung, Rechte, Sicherheit und Geschäftsdaten nicht abnehmen.

Coding Agents wie Codex helfen beim Verständnis eines Repositorys, bei Implementierung, Review, Debugging, Tests und Migration. Sie sind Entwicklungspartner. Für Zahlungsabwicklung, Zugriffsgrenzen, Produktionsgeheimnisse, Verbrauchswarnungen und Nutzerfeedback bleibt eine verantwortliche Person nötig.

Entscheidungstabelle zur Automatisierungsgrenze

Automatisierung	Am ersten Tag sinnvoll	Zusätzliches Risiko	Verbrauchsgrenze
Deployment	Nach Git push bauen und deployen	Build-Kontingent überschritten; niemand erhält Fehler	Pages-Builds und Timeout
Benachrichtigung	Zahlungs-Event → Berechtigung → Bestätigung	Webhook ohne Retry; Nachricht und Recht widersprechen sich	Workers-Anfragen, CPU, Retries
Backup	Kritische Daten exportieren; Plattformbackup im Paid-Plan aktivieren	Free enthält kein automatisches Backup; Exportfehler bleibt unbemerkt	Datenbankgröße, Speicher, Wiederherstellung
Auswertung	GA4/GSC regelmäßig exportieren und Bericht erzeugen	Zu häufig; API-Kontingente und Datenverzug ignoriert	GA4/GSC API quota
Komplexe Orchestrierung	Zahlung → Zugriff → E-Mail → CRM beobachtbar ausführen	Ein Fehler bricht die Kette; keine Idempotenz oder Rollback	Fehler pro Schritt, Retries, Dead Letters
Systemübergreifend	Webhook, API, Cron, E-Mail und CRM verbinden	Unterschiedliche Latenz; keine einheitlichen Fehlerlogs	Dynamische Anfragen, Queues, externe API-Kontingente

Grenzwerte für Webhook, API und Cron

Webhooks, leichte APIs und Cron-Jobs können auf Cloudflare Workers laufen, doch aktuelle Plattformgrenzen gehören in die Kostenübersicht:

• Workers Free: 100.000 requests/day und 10 ms CPU/invocation.
• Workers Paid: ab 5 US-Dollar pro Konto und Monat; Standard enthält 10M requests/month und 30M CPU ms/month, darüber nutzungsabhängige Kosten.

Statische Assets und dynamische Worker-Anfragen haben unterschiedliche Abrechnungsregeln. Überwache Anfragen, CPU, Retries, Logs, KV, Queues, R2 und verbundene Produkte gemeinsam statt nur eine „kostenlose Anfragezahl“.

Deployment-Warnungen, Zahlungsbestätigung, Feedback-Zuordnung und periodische Zusammenfassungen eignen sich früh. Automatische Rückerstattungen, Löschen von Produktionsdaten, Rechteänderungen, Massenversand und Preisänderungen brauchen eine Freigabe, bis Audit, Idempotenz und Rollback geprüft sind.

Kostengrenzen: Ein kostenloses Kontingent ist kein Architekturversprechen

Ein kostenloses Kontingent ist Startbudget, kein Architekturversprechen. Cloudflare- und Supabase-Grenzen hängen von dynamischen Anfragen, CPU, Speicher, Egress, Builds, Logs und Nutzungsmustern ab. „Für immer kostenlos“ oder eine feste Nutzerzahl lässt sich nicht versprechen.

Kosten- und Grenzwerttabelle

Dienst	Kostenloses Kontingent	Bezahlter Einstieg oder Upgrade	Änderungsrisiko	Zu überwachende Grenze
Cloudflare Pages	500 builds/month, 20.000 files, 25 MiB asset, 20 Minuten Build-Timeout	Pages-Limits über den passenden Cloudflare-Kontoplan erweitern	Kontingente und Pläne können sich ändern	Builds, Dateien, Timeout
Cloudflare Workers	100.000 requests/day, 10 ms CPU/invocation; statische Asset-Anfragen kostenlos	Paid ab $5/account/month, inklusive 10M requests und 30M CPU ms	Preis, CPU, Anfragen und Produktkontingente ändern sich	Anfragen, CPU, Retries, Warnungen
Supabase	50.000 MAU, 500 MB database, 1 GB storage, 5 GB egress, 2 Free projects; inaktive Projekte können nach einer Woche pausieren	Pro $25/month inklusive $10 compute credits	Projekt-, Compute-, Traffic- und Sicherheitsgrenzen ändern sich	MAU, Datenbank, Speicher, Egress, Aktivität

Die Werte wurden am 26. Juli 2026 mit Cloudflare Pages limits, Workers pricing und Supabase pricing abgeglichen. Beim Start sollten die offiziellen Seiten erneut geprüft werden.

Ein inaktives Supabase-Free-Projekt kann nach einer Woche pausieren, und Free enthält keine automatischen Backups. „Das Projekt öffnet sich“ ist kein Gesundheitstest. Prüfe Aktivität, Export, Wiederherstellung und Upgrade-Auslöser.

Weitere Cloudflare-Grenzen stehen in der Checkliste für Cloudflare Free und im Cloudflare-Planvergleich.

Zusammenfassung

Das minimale Geschäftssystem eines Solo-Founders ist keine kurze Werkzeugliste. Jede wichtige Geschäftsaktion braucht Einstieg, Ergebnis und Fehlerweg: Nutzer kommen an, erhalten das Produkt, zahlen, bekommen Zugriff, erzeugen Daten, senden Feedback und erhalten bei Störungen Hilfe.

Die erste Version muss nicht perfekt, aber prüfbar sein. Lege launch-checklist.md neben das Repository und spiele Zahlung, Rechte, Events, Feedback und Störung entlang eines echten Nutzerwegs durch. Frontend, Backend, Deployment, Datenbank, Zahlung und Analyse können später wachsen, ohne wegen einer fehlenden Übergabe alles neu zu bauen.