So wählst du den Tech-Stack für dein Solo-Business: Content, Tools und SaaS

Auf dem Aufgabenboard eines Solo-Entwicklers stehen oft dieselben Punkte: Domain kaufen, Content-Website aufsetzen, ein kleines Tool zur Nachfrageprüfung bauen, einen Bezahlknopf ergänzen, im GSC-Dashboard den Traffic prüfen und eine Fehlerwarnung einrichten. Hinter jedem Punkt steckt eine technische Wahl: Welches Framework trägt die Content-Website, wo läuft das Tool, welches Zahlungssystem passt und wohin gehen die Logs?

In einem Ein-Personen-Unternehmen fängt kein anderes Team eine schlechte Stack-Entscheidung auf. Ein späterer Wechsel kostet deshalb viel Zeit. Die häufige Frage „Welchen Tech-Stack sollte ein Solo-Founder verwenden?“ hat keine Standardantwort. Content-Websites, Webtools und SaaS-Produkte brauchen unterschiedliche Stacks. Grenzen kostenloser Pläne, Zahlungsdesign und die Verantwortung von KI-Tools lassen sich nicht durch das Kopieren eines fremden Pakets lösen.

Hilfreich ist eine Systemkarte: Bestimme zuerst das Geschäftsmodell – Content-Website, Webtool oder SaaS –, ordne anschließend die sechs Systemebenen zu und wähle erst danach konkrete Werkzeuge. Entscheidend ist der Rahmen, nicht das fertige Paket.

Ein Solo-Founder-Tech-Stack ist eine Systemkarte, kein festes Paket

Für ein Ein-Personen-Unternehmen gibt es keinen universellen Stack. Content-Websites, Webtools und SaaS-Produkte funktionieren unterschiedlich und brauchen daher andere technische Grundlagen. Auch Fähigkeiten, Budget und Phase unterscheiden sich. Ein „perfekter Stack“ für alle ist deshalb unmöglich.

Betrachte den Stack als sechs zusammenarbeitende Systemebenen:

Systemebene	Hauptziel	Typische Werkzeuge	Entscheidungspunkte
Content-Akquise	SEO-Einstieg und langfristige Reichweite	Astro/Next.js/Hugo, Cloudflare Pages/Vercel	Statisches Framework, Hosting-Grenzen, E-E-A-T und Grenzen für KI-Inhalte
Tool-Validierung	Nachfrage schnell und kostengünstig prüfen	Cloudflare Workers, Supabase, PlanetScale	Workers-Grenzen, kostenlose Kontingente und Zeitpunkt für einen kostenpflichtigen Plan
SaaS-Monetarisierung	Benutzer, Zahlungen und Abonnements verwalten	Supabase Auth, Stripe, PostgreSQL	Stripe Products/Prices, Fehler im Zahlungsdesign und Einmalkauf gegenüber Abo
Automatisierung	Wiederkehrende Entwicklungsarbeit mit KI-Coding-Tools reduzieren	Codex, Claude Code, Cursor	Grenzen der KI-Tools, delegierbare Aufgaben und eigene Entscheidungen
Datenkreislauf	Analyse, Feedback und Iteration verbinden	Google Search Console, Google Analytics, PostHog, Giscus/Discord	GSC-Abläufe, Analysewerkzeug und Feedbackkanal
Sicherheit und Betrieb	Logs, Warnungen und Rollbacks absichern	Cloudflare Logs, Sentry, Git rollback	Log-Praxis, Alarmierung und Wiederherstellung

Die Reihenfolge lautet: Geschäftsmodell bestimmen, sechs Ebenen zuordnen und dann Werkzeuge wählen. Wer zu Beginn nach dem „besten“ Stack sucht, baut oft mehr, ohne das eigentliche Risiko zu senken.

Zuerst entscheiden: Content-Website, Webtool oder SaaS?

Die drei Geschäftsmodelle unterscheiden sich bei Akquise, Validierungsdauer, Monetarisierung und technischer Komplexität:

Geschäftsmodell	Akquiseweg	Validierungsdauer	Monetarisierung	Stack-Komplexität	Typische Projekte
Content-Website	SEO und langfristiger Aufbau	Wirkung nach 6–12 Monaten	Werbung, bezahltes Wissen und Content-Erlöse	Mittel (statisches Framework + SEO)	Blogs, Tutorials und Ressourcenseiten
Webtool	Product Hunt und Community-Werbung	Schnelle Prüfung in 1–3 Monaten	Einmalkauf und kleine Abos	Niedriger (Workers + Supabase)	Kleine Tools, API-Werkzeuge und Konverter
SaaS	SEO + Produktvermarktung	Stabile Prüfung in 3–6 Monaten	Monats- und Jahresabos	Höher (Benutzer + Zahlung + Abo)	B2B-SaaS und abonnierte Tools

Beantworte vier Fragen:

1. Was ist deine stärkste Fähigkeit? Schreiben und SEO sprechen für Content, schnelle Entwicklung für ein Webtool und verlässlicher Produktbetrieb für SaaS.
2. Wo befinden sich deine Nutzer? Content-Nutzer kommen über Suche, Tool-Nutzer häufig über Product Hunt und Communities, SaaS verbindet Suche mit Produktvermarktung.
3. Wie lang ist dein Validierungszeitraum? Content kann 6–12 Monate brauchen, ein Tool 1–3 Monate und SaaS 3–6 Monate stabiler Signale.
4. Welches Erlösmodell erwartest du? Content nutzt Werbung oder Wissensprodukte, Tools häufig Einmalkäufe oder kleine Abos und SaaS meist Monats- oder Jahresabos.

Content-Akquise: SEO-Einstieg und E-E-A-T

Eine Content-Website ist die Akquiseoberfläche. Sie braucht ein statisches Framework, SEO-Arbeit und Hosting. Googles E-E-A-T-Prinzipien und die Grenzen für KI-gestützte Inhalte prägen den redaktionellen Prozess.

Cloudflare Pages ist ein gängiges Hosting-Angebot, hat aber Planlimits:

Grenze	Free	Pro ($20/month)	Business ($200/month)
Builds/month	500	5,000	20,000
Files/site	20,000	100,000	100,000
File size	25 MiB	25 MiB	25 MiB
Functions	Zählt zum Workers quota	Zählt zum Workers quota	Zählt zum Workers quota

Mehr als 500 Deployments pro Monat erfordern einen Plan oberhalb von Free. Dasselbe gilt bei mehr als 20.000 Dateien. Pages Functions zählen zu den Workers-Kontingenten, daher muss eine Content-Website mit Edge Functions auch die Request-Grenzen von Workers beobachten.

E-E-A-T steht für Experience, Expertise, Authoritativeness und Trustworthiness. Google betrachtet nicht den bloßen KI-Einsatz als Problem, sondern Inhalte mit geringem Wert. KI-gestützte Texte brauchen weiterhin menschliche Prüfung, eigene Erfahrung, klare Urheberschaft und verlässliche Quellen.

Bei statischen Blog-Frameworks gilt:

• Astro passt zu Content-Websites mit Fokus auf Performance und SEO und wird von Cloudflare Pages unterstützt.
• Next.js passt zu einer Mischung aus Content und Tool-Funktionen. SSR und SSG sind flexibel, die Konfiguration ist aber aufwendiger als bei Astro.
• Hugo passt zu rein statischen Content-Websites und baut sehr schnell, sein Ökosystem ist jedoch kleiner als das von Astro oder Next.js.

Tool-Validierung: günstige Experimente und Cloudflare-Workers-Grenzen

Ein Webtool ist die Validierungsebene. Es kombiniert häufig statisches Hosting, Edge Functions und eine Datenbank. Entscheidend sind die Grenzen von Cloudflare Workers und der Punkt, an dem das kostenlose Kontingent nicht mehr zur Last passt.

Preise für Cloudflare Workers:

Abrechnungsposten	Free	Paid ($5/month minimum)
Requests/day	100,000	Standard: 10M included/month, beyond $0.30/million
CPU time/invocation	10ms	Standard: 30M CPU ms/month included
Static assets	Kostenlos und unbegrenzt	Kostenlos und unbegrenzt
KV reads/day	100,000	Standard: 1M included/month, beyond $0.50/million

Free kann ein frühes Produkt tragen, ist aber auf 100K Requests pro Tag und 10ms CPU-Zeit pro Aufruf begrenzt. Darüber wird Paid nötig. Der Plan beginnt bei $5 pro Monat, enthält 10M Requests im Monat und berechnet danach $0.30 je weiterer Million. Statische Assets wie CSS, JavaScript und Bilder sind kostenlos und unbegrenzt, Requests an Edge Functions zählen jedoch zum Kontingent.

Preise für Supabase:

Abrechnungsposten	Free	Pro ($25/month)
MAU	50,000	100,000 included, beyond $0.00325/MAU
Database	500MB	8GB included, beyond $0.125/GB
Storage	1GB	100GB included, beyond $0.021/GB
Egress	5GB	50GB included, beyond $0.09/GB
Active projects	2	10
Pause policy	Pause nach 1 inaktiven Woche	Keine Pause

Free ermöglicht einen Start mit 50K MAU, einer 500MB-Datenbank, 1GB Speicher und 5GB Egress. Bei mehr als 50K Nutzern oder einer Datenbank über 500MB wird Pro nötig. Ein inaktives Free-Projekt wird nach einer Woche pausiert und muss manuell wiederhergestellt werden.

Eine typische Startkombination nutzt Cloudflare Workers für Edge Functions, Supabase für Datenbank und Auth sowie Stripe für Zahlungen. Sie kann zu einer frühen Last passen, braucht aber Schwellen für 100K Workers-Requests pro Tag, 500MB Supabase-Datenbank und 50K MAU.

SaaS-Monetarisierung: Benutzer, Stripe Products/Prices und Zahlungsfallen

SaaS ist die Monetarisierungsebene. Dafür braucht es Benutzerverwaltung, Datenbank, Zahlungen und Abo-Management. Stripes Products/Prices-Modell und frühe Entscheidungen zum Bezahlen prägen das übrige System.

Stripe Products/Prices:

Objekt	Zweck	Typischer Einsatz
Product	Definiert Produktname und Beschreibung	SaaS-Produkt oder kostenpflichtiges Tool
Price	Definiert einmaligen oder wiederkehrenden Preis, Betrag und Währung	$9.99 monatlich, $99.99 jährlich oder $49.99 einmalig
Subscription	Verwaltet Zeitraum und Status eines Abos	Monats- oder Jahresabo
Customer	Verknüpft Kunden und Zahlungsmethoden	Benutzerkonto

Ein Product kann mehrere Prices besitzen: $9.99 monatlich, $99.99 jährlich und $49.99 als Einmalkauf. Auch mehrere Währungen sind möglich, etwa USD $9.99, EUR €9.99 und CNY ¥69.99. Deshalb sollte früh geklärt werden, ob Abonnements, Einmalkäufe und mehrere Währungen unterstützt werden.

Supabase Auth stellt die Benutzerverwaltung bereit und umfasst in Free 50K MAU. Darüber wird Pro nötig. Unterstützt werden E-Mail sowie Anbieter wie Google, GitHub und Apple.

Typische Fallen im Zahlungsdesign:

• Erst kurz vor dem Start fällt auf, dass Abo und Einmalkauf anderen Code brauchen. Ein späteres Abo verändert Product/Price, Checkout-Logik und Abo-Verwaltung.
• Erst kurz vor dem Start fällt auf, dass mehrere Währungen einen Umbau erfordern. EUR oder CNY nach einem reinen USD-Start verändern Price, Checkout und Wechselkursbehandlung.
• Kündigung und Erstattung sind nicht definiert. Beide Abläufe müssen explizit sein, damit der Kontostatus nach dem Zahlungsende eindeutig bleibt.

Eine typische Kombination verwendet Supabase Auth für Benutzer, PostgreSQL für Daten und Stripe für Zahlungen. Sie eignet sich für ein frühes Produkt, ersetzt aber nicht die Entscheidung, ob Abo, Einmalkauf und mehrere Währungen zum ersten Umfang gehören.

Automatisierung: KI-Coding-Tools arbeiten mit, ersetzen aber keine Entscheidungen

KI-Coding-Tools sind eine Effizienzebene für Solo-Founder und kein Ersatz für technische Entscheidungen. Wichtig ist die Trennung zwischen Aufgaben für Codex und Entscheidungen, die beim Entwickler bleiben.

Codex ist ein Coding Agent von OpenAI, der Dateien lesen und bearbeiten, Tests ausführen und Prüfwerkzeuge aufrufen kann. Seine Grenzen:

• Er kann Code schreiben, Änderungen prüfen, Fehler debuggen und Aufgaben automatisieren.
• Er ersetzt keine technischen Entscheidungen zu Architektur, Stack, Risiko oder Geschäftslogik.
• Cloud-Workflows können 1–30 Minuten asynchron laufen und sind kein Echtzeit-Pairing.
• Er verwendet OpenAI-Modelle und erlaubt keinen beliebigen Modellwechsel.
• Cloud-Aufgaben laufen in verwalteten Umgebungen statt direkt auf dem lokalen Rechner des Entwicklers.
• Die Nutzung asynchroner Aufgaben kann relevante Kosten erzeugen.

Die Werkzeuge haben unterschiedliche Rollen:

• Codex bietet Cloud-Workflows für asynchrone Implementierung, Review, Debugging und Automatisierung; die technischen Entscheidungen bleiben beim Nutzer.
• Claude Code unterstützt interaktive Implementierung, Review und Debugging mit Claude-Modellen.
• Cursor integriert KI in den Editor und unterstützt dort Implementierung, Review und Debugging; für breitere Nutzung ist ein kostenpflichtiges Abo nötig.

Eine mögliche Kombination ist Codex Cloud für asynchrone Aufgaben, Claude Code für interaktive Arbeit und Cursor für die Editor-Integration. Sie deckt mehrere Arbeitsformen ab, alle drei Werkzeuge bleiben jedoch in der Zusammenarbeitsebene.

Nutze KI für Implementierung, Review, Debugging und wiederkehrende Automatisierung. Architektur, Stack-Entscheidung, Risikobewertung und Geschäftslogik bleiben deine Aufgabe. Generierter Code kann falsch sein, deshalb gehören menschliches Review und Abnahme in den Ablauf.

Datenkreislauf und Betrieb: Ebenen für Optimierung und Stabilität

Solo-Founder verschieben häufig Analyse, Kundenfeedback, Sicherheit und Betrieb. So entsteht ein Produkt ohne verlässlichen Lernkreislauf und ohne schnellen Wiederherstellungsweg bei Produktionsfehlern.

Datenkreislauf: GSC, Analyse und Kundenfeedback

Praktische Aufgaben in der Google Search Console:

• Prüfe Indexierung, Suchtraffic, Crawlingfehler und manuelle Maßnahmen in der Search Console.
• Werte Position, Klicks, Impressionen und CTR im GSC-Leistungsbericht aus.
• Verfolge Query-Änderungen, um die Wirkung einer SEO-Anpassung zu prüfen.

Mögliche Analysewerkzeuge:

• Google Analytics ist kostenlos und funktionsreich, bringt aber Datenschutzabwägungen und Datenverzögerung mit.
• PostHog ist Open Source und bietet Produktanalyse, Event-Tracking und Session Replay für die Produktiteration.
• Plausible ist Open Source, datenschutzorientiert und für Content-Websites einfacher.

Feedbackkanäle:

• Giscus basiert auf GitHub Discussions und eignet sich für Blogkommentare und öffentliches Feedback.
• Discord eignet sich für Community-Feedback zu Webtools und SaaS.
• E-Mail ist ein klassischer Kanal für alle drei Geschäftsmodelle.

Die Datenebene schließt den Kreislauf: GSC zeigt Akquise, Analyse zeigt Verhalten und Supportkanäle liefern Rückmeldungen für die nächste Iteration.

Sicherheit und Betrieb: Logs, Warnungen und Rollbacks

Für Logs:

• Cloudflare Logs zeigen Request-, Fehler- und Performancedaten von Workers.
• Supabase Logs zeigen Aktivitäten von Datenbank, Auth und API.

Für Warnungen:

• Sentry bietet Fehler- und Performance-Monitoring sowie Benachrichtigungen für SaaS.
• Cloudflare Alerts meldet Workers-Fehler und Traffic-Änderungen für Webtools.

Für Rollbacks:

• Verwende git revert oder git reset, um Quellcode zurückzusetzen.
• Wähle im Cloudflare-Pages-Dashboard ein früheres Deployment, um eine Veröffentlichung zurückzurollen.

Der Betrieb hält den Dienst stabil: Logs erklären Fehler, Warnungen verkürzen die Erkennungszeit und ein geprüfter Rollback begrenzt die Dauer eines Vorfalls.

Zusammenfassung

Der Tech-Stack eines Solo-Business ist eine Systemkarte und ein Entscheidungsrahmen, kein festes Paket. Bestimme, ob dein aktuelles Geschäft eine Content-Website, ein Webtool oder SaaS ist, ordne die sechs Ebenen zu und wähle erst danach Werkzeuge.

Die wichtigsten Entscheidungspunkte:

• Content-Akquise: Cloudflare-Pages-Grenzen mit 500 Builds pro Monat in Free sowie E-E-A-T und Grenzen für KI-Inhalte.
• Tool-Validierung: Workers-Preise mit 100K Requests pro Tag in Free, 50K MAU bei Supabase Free und weitere Kontingente.
• SaaS-Monetarisierung: Stripe Products/Prices, Fallen im Zahlungsdesign und Abo gegenüber Einmalkauf.
• Automatisierung: KI-Coding-Tools arbeiten mit dem Entwickler, ersetzen aber keine technische Entscheidung.
• Daten und Betrieb: Diese Ebenen werden leicht übersehen, brauchen aber früh einen Platz im System.

Setze den Rahmen in vier Schritten um:

1. Bestimme das Geschäftsmodell: Content-Website, Webtool oder SaaS.
2. Ordne die benötigten Komponenten den sechs Ebenen zu.
3. Wähle Cloudflare, Supabase, Stripe, Cursor, Codex oder andere Werkzeuge erst nach der Grenzziehung.
4. Prüfe kostenlose Kontingente, Zahlungsdesign und KI-Verantwortung, bevor daraus Migrationsarbeit wird.

Ein wartbarer, praktischer Stack ist wertvoller als eine Sammlung der gerade beliebtesten Technologien.

Nächste Schritte und weiterführende Artikel

Lies bei der Ebene weiter, die deinem aktuellen Engpass entspricht:

• Backend-Stack für Solo-Founder auswählen: Cloudflare Workers, Supabase, Node.js und Datenbankgrenzen vergleichen.
• Datenbanken und Speicher für Solo-Founder auswählen: Rollen von D1, Postgres, R2, S3 und SQLite trennen.
• Deployment-Plattform für Solo-Founder auswählen: Cloudflare Pages, Workers, Vercel und Railway vergleichen.
• Zahlungs-Stack für Solo-Founder auswählen: Stripe, Paddle, Lemon Squeezy und WeChat Pay vergleichen.

Die vertiefenden Artikel machen aus jeder Ebene eine konkrete Entscheidung, ohne die gesamte Systemkarte auf eine Werkzeugliste zu reduzieren.