Wie man allein ein KI-Startup aufbaut

Rustam Atai10 Min.

Noch vor ein paar Jahren klang die Formulierung "ein KI-Startup allein aufbauen" wie eine schöne Fantasie. Heute ist das keine Fantasie mehr, sondern ein durchaus praktikables Format für die erste Phase. Nicht weil es leicht geworden wäre, allein ein Unternehmen aufzubauen. Sondern weil KI die Kosten von Experimenten drastisch gesenkt hat: Was früher einen Designer, einen Frontend-Entwickler, einen Backend-Entwickler, DevOps und etwas Glück brauchte, kann heute oft von einer Person auf fertiger Infrastruktur und mit API-Modellen zusammengesetzt werden. Der Markt selbst spiegelt diese Realität gut wider: OpenAI entwickelt ein eigenes Programm für Startups, Vercel positioniert sich ausdrücklich als Plattform für KI-Anwendungen, und Supabase verkauft nicht nur eine Datenbank, sondern ein fertiges Fundament für produktionsreife Anwendungen mit Auth, Storage, Functions und Vector Embeddings. (OpenAI)

Wichtig ist hier aber, nicht in einen anderen Mythos zu verfallen. KI macht ein Startup nicht "kostenlos" und hebt die alte Wahrheit nicht auf: Menschen brauchen nicht "noch eine KI". Sie brauchen ein Werkzeug, das Zeit, Geld und Nerven spart oder die Arbeit spürbar besser macht. Ein Solo Founder mit KI gewinnt nicht durch Größe, sondern durch Geschwindigkeit. Sein Vorteil liegt nicht darin, dass er alles bauen kann, sondern darin, dass er sehr schnell testen kann, wofür Menschen bereit sind zu zahlen. Das ist die neue Normalität: kein Unternehmen zwölf Monate im Voraus aufzubauen, sondern in Tagen und Wochen ein nützliches Mikroprodukt zu starten, solange die Kosten eines Fehlers noch klein sind. (OpenAI)

Solo Founder + KI = die neue Normalität

Wenn man ehrlich ist, hat KI den Gründer nicht ersetzt. Sie hat einen Teil der Routine rund um den Gründer ersetzt. Texte für die Landingpage, erste UX-Ideen, Rohcode, SQL-Generierung, Markup, Dokumentation, FAQ für den Kundensupport, Vorbereitung von Werbemitteln, Analyse von Feedback: All das lässt sich heute schneller erledigen als früher. Deshalb ist ein Solo-Launch nicht auf der Ebene von Romantik realistischer geworden, sondern auf der operativen Ebene. Wenn Hosting mit einem kostenlosen Hobby-Plan starten kann, Backend und Auth als Managed Service genommen werden können und Intelligenz als tokenbasierte API eingekauft werden kann, sinken die Eintrittskosten in den Markt drastisch. Vercel bietet einen kostenlosen Hobby-Plan, Supabase startet mit einem kostenlosen Tier und skaliert nutzungsbasiert, und OpenAI rechnet pro Modell ab, was für kleine MVPs bequem ist. (Vercel)

Genau darin liegt die Verschiebung. Früher scheiterte eine Einzelperson oft nicht an der Idee, sondern an der Infrastruktur: eine Datenbank aufsetzen, Authentifizierung bauen, Deployment anschließen, Dateispeicherung, Task-Queue, Logging, Payments. Heute lässt sich ein erheblicher Teil davon out of the box bekommen. Supabase bietet direkt Postgres, Authentication, instant APIs, Edge Functions, Realtime, Storage und Vector Embeddings auf einer Plattform, und Vercel ergänzt das um sehr schnelles Deployment und Infrastruktur für AI-first-Webanwendungen. (Supabase)

Deshalb ist es treffender, es so zu sagen: Solo Founder + KI ist nicht "eine neue Art, Unicorns zu bauen", sondern eine neue Art, günstig und schnell nach einem funktionierenden Markt zu suchen. Und das ist bereits eine enorme Veränderung.

No-Code und KI: Wo sie wirklich nützlich sind

Ein Solo Founder hat normalerweise ein Hauptproblem: weniger Zeit als Ideen. Genau hier sind No-Code und KI am nützlichsten. No-Code muss nicht euer finaler Stack sein. Seine Aufgabe ist es, schnell einen Nachweistest für Nachfrage zusammenzubauen. Eine kleine Landingpage, ein Lead-Formular, eine Waitlist, ein Demo-Szenario, Onboarding, eine Datenbank der ersten Nutzer, einfache Analytics: All das ist oft sinnvoller, möglichst schnell zusammenzubauen, als "schön und richtig".

KI wird in diesem Setup nicht für Magie gebraucht, sondern zur Beschleunigung. Sie hilft dabei, Texte ohne lange Iterationen zu schreiben, einen groben UI-Entwurf zu generieren, mehrere Sprachen zu unterstützen, Positionierungsvarianten vorzubereiten, Daten aus Dokumenten zu extrahieren, Nutzeranfragen automatisch zu klassifizieren und Zusammenfassungen zu erstellen. Das reduziert den Umfang manueller Arbeit stark, der früher Wochen verschlungen hat. Vercel bewirbt sein AI SDK ausdrücklich als Toolkit für AI-native Interfaces, und Supabase baut schon lange KI-Szenarien rund um Embeddings, pgvector und die automatische Aktualisierung von Vektorindizes auf. (AI SDK)

Es gibt aber eine wichtige Grenze. No-Code und KI sind dort gut, wo man eine Hypothese schnell prüfen muss. Sobald ihr echte Nachfrage, zahlende Nutzer und wiederholte Nutzung seht, ist es besser, nicht mit der Realität zu streiten und damit zu beginnen, das Produkt in eine robustere Architektur zu überführen. Nicht alles muss für immer in No-Code leben.

Minimaler Stack: OpenAI + Supabase + Vercel

Wenn man einen wirklich minimalen und praktischen Stack für ein Solo-KI-Startup braucht, wirkt die Kombination aus OpenAI, Supabase und Vercel heute fast wie ein Referenzstandard.

OpenAI deckt die "Intelligenz" des Produkts ab: Chat, Bedeutungsextraktion, Klassifizierung, Generierung, Zusammenfassung, Suche in Inhalten und agentische Szenarien. Auf der offiziellen Seite zum Modell GPT-5.4 werden Tool-Support, großer Kontext, strukturierte Outputs sowie ein Preis ab 2,50 $ pro 1 Mio. Input-Tokens und 15 $ pro 1 Mio. Output-Tokens genannt, was das Modell sowohl für ernsthafte Szenarien als auch für die Kontrolle der Produkteinheitökonomie geeignet macht. (OpenAI Developers)

Supabase deckt fast das gesamte Backend-Skelett ab: Datenbank, Auth, Storage, Realtime, Edge Functions und Vector Embeddings. Das ist für einen Solo Founder besonders wertvoll, weil man nicht Wochen damit verbringen muss, die übliche Server-Grundverkabelung zusammenzubauen. Außerdem orientiert sich die Plattform direkt an KI-Use-Cases und an der Unterstützung von Vektorsuche. Auf der Pricing-Seite von Supabase steht, dass Pro bei 100.000 MAU beginnt und danach nutzungsbasiert skaliert, während die grundlegende Einstiegsschwelle niedrig bleibt. (Supabase)

Vercel deckt die Auslieferung des Produkts an den Nutzer ab: Deployment, CDN, CI/CD, schnelle Veröffentlichung und ein komfortables Umfeld für Next.js und KI-Interfaces. Auf der offiziellen Pricing-Seite von Vercel ist Hobby als free forever ausgewiesen und Pro mit 20 $ pro Monat plus Nutzung, inklusive 20 $ Usage Credit. Für ein MVP ist das fast ein idealer Kompromiss zwischen Geschwindigkeit und Kosten. (Vercel)

Warum passt gerade dieser Stack so gut zu einer Einzelperson? Weil er die Zahl der "nicht geschäftlichen" Entscheidungen radikal reduziert. Ihr wählt nicht zwischen drei Clouds, vier Auth-Services und einem selbstgeschriebenen Backend. Ihr nehmt einen Stack, der euch erlaubt, schnell die einzige wichtige Frage zu beantworten: Wer ist hier bereit, wofür zu zahlen?

Wie man ein MVP in einer Woche baut

Der Satz "ein MVP in einer Woche bauen" nervt Ingenieure normalerweise, weil er wie Infobusiness klingt. Und diese Reaktion ist berechtigt, wenn man unter MVP ein "fertiges Produkt" versteht. Wenn man darunter aber die erste bezahlte Validierung von Nutzen versteht, dann ist eine Woche kein Wahnsinn.

Am ersten Tag programmiert ihr nicht. Ihr formuliert einen Schmerzpunkt und einen Nutzer. Nicht "KI für Business", sondern zum Beispiel "ein Tool, das in 3 Minuten die wichtigsten Punkte aus einem Mietvertrag extrahiert" oder "ein Service, der Calls in eine kurze Liste von Follow-up-Aufgaben verwandelt". Wenn sich das Problem nicht in einem Satz beschreiben lässt, habt ihr noch kein MVP.

Am zweiten Tag baut ihr eine Landingpage, einen Login-Screen und ein Szenario, das sichtbaren Nutzen liefert. Nicht fünf Szenarien. Eines. Ein Upload-Screen, ein Ergebnis-Screen, eine Erfolgsmetrik. In diesem Moment sind No-Code, Templates und KI-generierte Interfaces nützlicher als architektonischer Stolz. (Vercel)

Am dritten Tag schließt ihr die Intelligenz an. In den meisten Fällen ist das kein "komplexes KI-System", sondern ein gut durchdachter Prompt, begrenzter Input, ein verständliches Output-Format und Logging der Ergebnisse. Hier ist Vorhersehbarkeit wichtiger als technologische Coolness. Ein gutes MVP wird häufiger auf einer zuverlässigen Pipeline gebaut als auf fünf "smarten" Agenten.

Am vierten Tag fügt ihr Billing oder zumindest Vorbestellungen hinzu. Ein MVP ohne Preis ist kein Business-Test, sondern ein Neugier-Test. Wenn es euch noch Angst macht, Geld zu nehmen, könnt ihr eine Waitlist mit einem konkreten Angebot machen oder mit Vorkasse für die ersten Nutzer starten.

Am fünften Tag beginnt ihr, das Produkt Menschen zu zeigen. Nicht Freunden, die es loben werden. Sondern denen, die genau diesen Schmerz haben. Hier ist sogar halbmanueller Service sinnvoll, wenn er hilft, Nachfrage zu prüfen. Die Geschichte von Fireflies zeigt die Logik dieses Ansatzes gut: In einer frühen Phase machten die Gründer manuell Notizen für mehr als 100 Meetings, um zuerst den Wert des Szenarios zu validieren und es erst danach mit Code zu automatisieren. Das ist aus ethischer Sicht ein umstrittener Fall, aber aus Produktsicht ist die Lehre sehr stark: zuerst bestätigen, dass das Ergebnis gebraucht wird, dann komplexe Mechanik bauen. (Business Insider)

Am sechsten und siebten Tag schaut ihr nicht auf Lob, sondern auf Verhalten. Kommen die Leute zurück? Laden sie eine zweite Datei hoch? Zahlen sie? Fragen sie nach Export? Fragen sie nach Teamzugang? Genau hier beginnt das echte Produkt.

Monetarisierung von KI-Tools

Der häufigste Fehler bei KI-Produkten ist der Versuch, Geld "für KI" zu nehmen. Der Nutzer will nicht dafür bezahlen, dass bei euch intern ein Modell läuft. Er zahlt für das Ergebnis: Zeitersparnis, weniger Routine, eine verständliche Antwort, ein fertiges Artefakt, eingesparte Arbeitsstunden.

Bei KI-Tools funktionieren normalerweise drei Monetarisierungsmodelle gut.

Das erste ist Subscription. Sie passt, wenn das Produkt regelmäßig genutzt wird: Meeting-Notizen, Dokumentenzusammenfassungen, ein KI-Assistent für Support, ein Content-Generator, Analyse eingehender Anfragen. Der Nutzer bezahlt für Gewohnheit und wiederholbaren Nutzen.

Das zweite ist usage-based. Es ist besonders natürlich dort, wo es eine verständliche Verbrauchseinheit gibt: Anzahl von Dokumenten, Audiominuten, Generierungen, Anfragen, Credits. Ein solches Modell passt gut zu euren eigenen Kosten, weil auch OpenAI und ähnliche Services usage-based abrechnen. In der Praxis reduziert das das Risiko, unter den eigenen Infrastrukturkosten zu verkaufen. Die offiziellen Seiten von OpenAI und Copy.ai spiegeln diese Logik usage-basierter Preisgestaltung direkt wider. (OpenAI Developers)

Das dritte ist Freemium mit einem harten Limit. Es funktioniert, wenn man schnell Nutzer gewinnen und ihnen den Geschmack des Produkts zeigen will, ohne an Tokens bankrottzugehen. Zum Beispiel: 5 kostenlose Dokumente pro Monat, 20 kostenlose Summaries, 1 Projekt kostenlos, Export nur im bezahlten Tarif, Zusammenarbeit nur in Pro.

Wichtig ist: Bei KI-Tools muss Monetarisierung gleichzeitig mit dem Produkt entworfen werden. Wenn ihr den Nutzer zuerst an "unendlich kostenlose KI" gewöhnt und euch erst danach an die Kosten erinnert, wartet ein sehr unangenehmes Gespräch mit der Realität auf euch.

Beispiele für Indie-KI-Projekte

Ein gutes Indie-KI-Projekt sieht fast immer langweiliger aus, als der Gründer es gern hätte. Und genau deshalb hat es bessere Chancen, Geld zu verdienen.

Die erste Klasse solcher Projekte sind Utilities rund um Dokumente. PDF hochladen, Summary bekommen, Antworten auf Fragen, Extraktion von Schlüsselfeldern, Struktur, Tabelle, Follow-up. Das ist ein klarer Schmerz und ein klares Wertversprechen. Der Markt zahlt dafür: PDF.ai hat eine eigene Pricing-Seite mit Tarifen von Starter bis Scale und darüber hinaus, das heißt, dieses Szenario ist kommerziell bereits normalisiert. (PDF.ai)

Die zweite Klasse ist AI Notetaking und Meeting Intelligence. Hier braucht der Nutzer keinen "smarten Bot", sondern eine kurze Zusammenfassung des Gesprächs und eine Liste von Aufgaben. Genau deshalb wächst diese Nische so schnell. Und genau deshalb eignet sie sich für einen Solo-Start: Sie hat einen sehr klaren Pain Point, einen verständlichen Nutzer und eine transparente Value Proposition. Die Geschichte der frühen Validierung von Fireflies zeigt, dass man noch vor komplexer Automatisierung zuerst prüfen kann, ob das Ergebnis selbst überhaupt gebraucht wird. (Fireflies.ai)

Die dritte Klasse sind enge B2B-Assistenten. Nicht "KI für Vertrieb", sondern zum Beispiel "KI, die eingehende Händleranfragen analysiert und nach Kategorien sortiert", "KI, die eine kurze Zusammenfassung eines Ausschreibungsdokuments erstellt", "KI, die Aufgaben aus Kunden-E-Mails extrahiert". Solche Produkte müssen nicht viral sein. Es reicht, wenn sie einer konkreten Rolle 30-60 Minuten pro Tag sparen.

Es gibt auch ganz kleine Fälle. Auf Indie Hackers gibt es ein Beispiel für ein Solo-Chat-PDF-Projekt, das der Autor in einer Woche gebaut und als eigenständiges SaaS gestartet hat. Das ist keine Geschichte über riesigen Erfolg, sondern genau über die richtige Größenordnung: ein kleines, enges, verständliches Produkt, das sich schnell in den Markt bringen lässt und mit dem man Nachfrage ertasten kann. (Indie Hackers)

Was ein erfolgreiches Solo-KI-Startup tatsächlich auszeichnet

Nicht die Geschwindigkeit der Code-Generierung. Nicht eine schöne agentische Pipeline. Nicht das Wort "KI" auf der Landingpage.

Ein erfolgreiches Solo-KI-Startup ruht fast immer auf drei Dingen. Das erste ist eine enge, schmerzhafte Aufgabe. Das zweite ist ein sehr kurzer Weg vom Input zum Ergebnis. Das dritte ist eine klare Ökonomie: wie viel ein Nutzer kostet, wie viel eine Operation kostet und wie viel ihr an einem zahlenden Kunden verdient.

Alles andere ist zweitrangig. Den Stack kann man wechseln. Das Modell kann man austauschen. Das Interface kann man neu gestalten. Aber wenn ihr vom ersten Tag an nicht versteht, welchen konkreten Schmerz ihr beseitigt und warum jemand dafür zahlen soll, wird euch keine KI retten.

Fazit

Heute ist es realistisch, allein ein KI-Startup aufzubauen. Aber nicht weil "jetzt alles das neuronale Netz macht", sondern weil Infrastruktur, Modelle und fertige Plattformen den ersten Schritt radikal verbilligt haben. OpenAI liefert Intelligenz als API, Supabase nimmt einen Großteil der Backend-Routine ab, Vercel beschleunigt den Weg in Produktion, und der Markt zeigt bereits, dass schmale KI-Utilities rund um Dokumente, Meetings und repetitive Knowledge Work durchaus monetarisierbar sind. (OpenAI Developers)

Die richtige Strategie für einen Solo Founder sieht nicht so aus wie "Ich baue ein großes KI-Business", sondern wie "Ich validiere in 7 Tagen einen teuren Schmerzpunkt". Und das ist keine Romantik mehr. Das ist funktionierende Disziplin.