Vibe-Coding-Ideen finden: Was du wirklich bauen solltest

Du hast einen Coding-Agenten geöffnet, bist motiviert und weißt trotzdem nicht, was du bauen sollst. Das ist kein Technikproblem. Es ist ein Ideenproblem: Die große App-Idee fühlt sich zu groß an, die kleinen Aufgaben zu banal.

Dabei liegen die besten ersten Projekte oft direkt vor dir. Ein Rechnungsabgleich, der jeden Monat unnötig Zeit kostet. Eine Reisegruppe, die Ausgaben über mehrere Währungen verteilt. Ein Geografie-Quiz, das du gerne länger spielen würdest. Oder eine Excel-Datei, deren interessante Fragen du bisher nur mit viel Filtern und Kopieren beantworten konntest.

In Folge 009 von Kontext.FM sammeln Martin und Trutz genau solche Beispiele. Der gemeinsame Gedanke dahinter: Du musst nicht zuerst ein Produkt für einen Markt erfinden. Du kannst Software für eine Person bauen – für dich. Dieser Artikel hilft dir, daraus eine konkrete, klein genug geschnittene Vibe-Coding-Idee zu machen. Nicht mit einer Liste beliebiger App-Vorschläge, sondern mit einem Verfahren, das bei deinem eigenen Alltag anfängt.

Die falsche Frage lautet: „Welche App fehlt noch?“

Wer nach einer Idee sucht, denkt schnell in Kategorien, die man aus Start-ups kennt: Problem groß genug? Zielgruppe groß genug? Lässt sich das verkaufen? Für ein erstes persönliches Tool sind das die falschen Maßstäbe.

Die bessere Frage lautet: Wo machst du gerade etwas Umständliches, obwohl die Regeln dafür eigentlich klar sind?

Das kann sehr unspektakulär sein:

• Du kopierst regelmäßig Werte aus zwei Exporten zusammen.
• Du suchst auf derselben Website immer wieder nach einer Identifikationsnummer.
• Du führst eine Liste, aber die Darstellung beantwortet deine Fragen nicht.
• Du beobachtest eine öffentliche Seite und möchtest eine andere Sortierung oder eine Benachrichtigung.
• Ein Dienst hat fast die richtige Funktion, zwingt dich aber zu einem unpassenden Ablauf.

Das sind keine Lücken im App Store. Es sind Reibungen. Und Reibung ist für ein persönliches Tool ein viel besseres Startsignal als eine vermeintlich einzigartige Idee.

Früher musste sich Software meist für viele Menschen lohnen, weil ihre Entwicklung teuer war. Heute ist die Eintrittsschwelle für einen lokalen Prototyp deutlich kleiner. Ein Tool darf unfertig sein, nur bei dir laufen und genau eine Sache erledigen. Es braucht dann weder Login, Bezahlmodell noch eine öffentliche Website.

Das bedeutet nicht, dass es keine Qualitätsansprüche gibt. Es bedeutet nur: Der Nutzen bestimmt den Umfang. Wenn ein kleiner CSV-Filter dir jeden Monat 30 Minuten abnimmt, ist er wertvoll, auch wenn ihn nie jemand anders sieht.

Das mentale Modell: Auslöser, Ablauf, Ergebnis

Eine brauchbare Projektidee lässt sich auf drei Bausteine zurückführen:

1. Auslöser: Was startet den Ablauf? Eine Datei, eine Website, eine Eingabe, ein Termin oder eine wiederkehrende Frage.
2. Ablauf: Was geschieht heute mühsam von Hand? Vergleichen, filtern, sortieren, nachschlagen, umrechnen oder erinnern.
3. Ergebnis: Was möchtest du danach direkt sehen, herunterladen oder entscheiden können?

Nimm den Rechnungsabgleich als Beispiel. Der Auslöser sind zwei monatliche Exporte aus getrennten Systemen. Der Ablauf ist das manuelle Zuordnen von Zahlung und Rechnung. Das Ergebnis ist eine Liste, die klar zeigt, welche Zahlung zu welcher Rechnung gehört und wo etwas fehlt.

Aus dieser Beschreibung kann ein Agent einen ersten Vorschlag machen. „Baue mir eine Buchhaltungs-App“ wäre dagegen viel zu offen. Dann erfindet der Agent Datenbank, Benutzerverwaltung und zehn Funktionen, die du gar nicht brauchst.

Dasselbe Muster funktioniert im Privaten. Beim Reise-Globus aus der Folge ist der Auslöser eine kleine Liste besuchter Länder und Reisen. Der Ablauf ist das Eintragen und Auswerten. Das Ergebnis ist eine persönliche Karte mit Statistiken, die genau die Fragen beantwortet, die ihren Nutzer interessieren. Technisch steckt dort möglicherweise eine anspruchsvolle Visualisierung dahinter. Entscheidend für den Anfang war aber nicht die Technologie, sondern die klare Vorstellung vom Ergebnis.

Vier Stellen, an denen gute Ideen liegen bleiben

Wenn dir spontan kein Projekt einfällt, gehe diese vier Fundorte durch. Notiere nur konkrete Situationen. Noch keine Lösung.

1. Wiederkehrende Handarbeit

Alles, was du regelmäßig per Copy-and-paste, Filter oder Taschenrechner erledigst, ist ein Kandidat. Besonders gut sind Abläufe mit festen Eingaben und einem klaren Resultat.

Typische Fragen dafür sind:

• Welche zwei Dateien muss ich immer wieder vergleichen?
• Welche Spalten bearbeite ich in Excel jedes Mal gleich?
• Welche Datei bereite ich vor einem Meeting mühsam auf?
• Welche Daten muss ich zusammenführen, um eine einfache Antwort zu erhalten?

In der Folge beschreiben die Hosts zum Beispiel den Abgleich von Stripe-Zahlungen und Rechnungen. Ein kleines Skript kann wiederholbare Zuordnungen erledigen und auf Abweichungen hinweisen. Du musst dafür nicht mit Buchhaltung anfangen: Schon ein Tool, das drei Exporte einliest, fehlende Werte markiert und eine neue CSV erzeugt, kann der richtige erste Schritt sein.

2. Ein Hobby mit klaren Regeln

Hobbys sind besonders gute Vibe-Coding-Projekte. Du kennst die Begriffe, merkst sofort, ob ein Ergebnis sinnvoll ist, und hast einen Grund, die erste unfertige Version wirklich zu testen.

Das Geo-Quiz aus der Folge ist dafür ein gutes Muster. Ausgangspunkt war kein abstraktes „Ich möchte ein Spiel programmieren“, sondern eine konkrete Frustration: Ein bevorzugtes Online-Quiz war nur einmal täglich spielbar. Daraus wurde ein eigenes lokales Spiel mit passenden Kategorien und später weiteren Datenpunkten.

Die übertragbare Idee ist nicht, ein bestehendes Produkt zu kopieren. Baue keine fremde Marke, Gestaltung oder geschützte Inhalte nach. Aber du kannst einen ähnlichen Bedarf eigenständig lösen: ein Vokabeltrainer für deine Fehler, eine Setlist-Übersicht für deine Band, ein Trainingslog mit den Kennzahlen, die dir fehlen, oder ein Vereinshelfer für wiederkehrende Aufgaben.

3. Daten, die mehr können als ihre Tabelle zeigt

In vielen Dateien steckt bereits eine gute Anwendung. Du brauchst keine neue Datenquelle, sondern eine bessere Frage an die vorhandene.

Der Registrierungs-Visualizer aus der Folge nutzt eine vorhandene Excel-Datei, um Marketingkanäle über Zeiträume zu vergleichen und Grafiken für Meetings bereitzustellen. Die Daten bleiben dabei im lokalen Tool auf dem Rechner; die AI wurde zum Erstellen des Werkzeugs genutzt, nicht zum Hochladen des kompletten Datensatzes.

Schau bei deinen Dateien deshalb nicht zuerst auf das Format, sondern auf die Fragen:

• Welche Entwicklung sehe ich in der Tabelle nicht auf einen Blick?
• Welche Gruppen oder Zeiträume möchte ich vergleichen?
• Welche Auswertung baue ich vor jedem Termin wieder neu?
• Welches Diagramm würde eine Entscheidung leichter machen?

Wenn personenbezogene, Kunden- oder andere vertrauliche Daten beteiligt sind, ist diese Trennung wichtig. Du kannst dem Agenten Tabellenstruktur, anonymisierte Beispieldaten und gewünschte Auswertung geben. Bevor du echte Daten in ein Tool oder einen Dienst lädst, prüfst du, wohin sie übertragen werden, wer Zugriff hat und ob die Nutzung im Unternehmen erlaubt ist. „Läuft lokal“ ist nur dann ein Datenschutzvorteil, wenn das fertige Tool die Daten tatsächlich nicht an externe Dienste sendet.

4. Kleine Brüche im Browser

Manche Arbeitsschritte passieren ausschließlich auf einer Website: immer wieder dieselbe Suche, eine fehlende Sortierung, viele einzelne Klicks oder ein Wert, der in der Oberfläche nicht gut erreichbar ist.

Hier können ein Browser-Tool, eine eigene Erweiterung oder sogar ein Bookmarklet passen. Ein Bookmarklet ist ein Lesezeichen, das beim Klick ein kleines JavaScript im aktuellen Browserfenster ausführt. In der Folge dient eines dazu, nach Eingabe einer ASIN direkt die passende Amazon-Produktseite zu öffnen.

Der Rahmen ist wichtig: Automatisiere nur, wozu du berechtigt bist. Nutzungsbedingungen, Zugriffsrechte und technische Schutzmaßnahmen gelten auch für ein persönliches Helferlein. Greife nicht aggressiv auf fremde Systeme zu, umgehe keine Schranken und teste bei öffentlichen Datenquellen mit niedriger Abruffrequenz. Für einfache Browser-Automatisierung ist oft die Frage „Kann ich diesen Schritt selbst legal im Browser ausführen?“ ein guter erster Filter – aber keine vollständige Rechtsprüfung.

Prüfe jede Idee mit dem Ein-Nutzer-Test

Nicht jede nervige Aufgabe ist ein gutes erstes Projekt. Bevor du loslegst, prüfe sie mit fünf Fragen:

1. Kann ich das Ergebnis selbst beurteilen? Ein Filterergebnis, eine Liste oder ein Diagramm kannst du kontrollieren. Eine medizinische Empfehlung oder eine komplizierte Steuerberechnung nicht ohne Weiteres.
2. Ist die erste Version klein? Formuliere sie ohne Wörter wie „Plattform“, „vollautomatisch“ oder „für alle“. Ein Input, ein Ablauf, ein Output reichen.
3. Sind Fehler reversibel? Das Tool sollte anfangs lesen, visualisieren oder einen Entwurf erzeugen – nicht automatisch Geld bewegen, Termine buchen oder Datensätze löschen.
4. Sind die Daten und Rechte geklärt? Nutze Testdaten, sichere Zugänge und nur Quellen, die du verwenden darfst.
5. Werde ich es diese Woche testen? Ein persönliches Tool gewinnt, wenn ein echter Anlass direkt vor der Tür steht.

Diese Fragen sortieren auch Projekte aus, die später sinnvoll sein können. Ein gemeinsamer Reisekosten-Tracker wird interessant, sobald mehrere Personen gleichzeitig Daten eingeben. Dann kommen Benutzerkonten, Synchronisierung, Backups und Deployment dazu. Das ist ein anderer Reifegrad als ein lokaler Ein-Nutzer-Prototyp – nicht schlechter, aber deutlich größer. Für diesen Übergang von localhost ins Internet hilft der Artikel Vibe-Coding-App hosten.

Groß denken, aber die erste Aufgabe absurd klein schneiden

Ein hilfreicher Trick ist, die Vision aufzuschreiben und sie direkt daneben zu verkleinern.

Große Idee	Erste nützliche Version
„Ich baue eine Reise-App für unsere Gruppe.“	„Ich erfasse drei Ausgaben und berechne, wer wem wie viel schuldet.“
„Ich analysiere unsere Marketingdaten.“	„Ich lade einen CSV-Export hoch und vergleiche einen Kanal in zwei Zeiträumen.“
„Ich will einen persönlichen Sprachtrainer.“	„Ich zeige mir zehn Wörter aus meiner Fehlerliste und speichere richtig/falsch.“
„Ich automatisiere die Konkurrenzbeobachtung.“	„Ich erstelle aus einer erlaubten Quelle einmal täglich eine Liste neuer Einträge.“

Die kleine Version ist kein schlechter Kompromiss. Sie beantwortet die entscheidende Frage: Ist der Ablauf nützlich? Erst wenn du sie mit echten Daten oder im Alltag verwendet hast, weißt du, welche zweite Funktion wirklich fehlt.

Genau so unterscheiden sich sinnvolle Iterationen von Feature-Sammlungen. Vielleicht brauchst du nach dem ersten Test einen Export. Vielleicht einen Zeitraumfilter. Vielleicht stellst du fest, dass die Aufgabe mit einer bestehenden Anwendung schneller gelöst ist. Auch das ist ein gutes Ergebnis: Du hast eine Annahme günstig geprüft.

Für einen Einstieg mit einer einzelnen lokalen HTML-Datei passt auch der Workflow aus AI Mini Tool in 10 Minuten. Wenn dein Projekt mehrere Dateien, lokale Skripte oder wiederkehrende Jobs braucht, ist das Vibe-Coding-Setup für Anfänger der passendere nächste Schritt.

Ein Prompt, der aus einer Reibung einen Test macht

Dieser Prompt ist absichtlich kein Bauauftrag für eine fertige App. Er zwingt dich und den Agenten zuerst zu einer kleinen, überprüfbaren Version:

Ich möchte ein kleines persönliches Tool bauen, nicht sofort eine App für andere.

Ausgangssituation:
[Beschreibe die nervige Aufgabe in zwei bis drei Sätzen.]

Eingabe:
[Datei, manuelle Eingabe, erlaubte Website oder Datenquelle]

Gewünschtes Ergebnis:
[Was möchtest du konkret sehen, herunterladen oder entscheiden können?]

Rahmen:
- Die erste Version soll nur lokal für mich laufen.
- Sie soll keine Daten löschen, versenden oder veröffentlichen.
- Verwende zunächst nur Beispieldaten oder eine anonymisierte Struktur.
- Wenn Daten einen externen Dienst verlassen könnten, erkläre das vorher.

Bevor du Code schreibst:
1. Stelle die fehlenden Rückfragen.
2. Beschreibe die kleinste testbare Version in einem Satz.
3. Nenne die einfachste passende technische Form: einzelne HTML-Datei,
   lokales Skript oder Browser-Erweiterung – mit kurzer Begründung.
4. Liste Risiken, Annahmen und den ersten manuellen Test auf.

Ein gutes Ergebnis nach diesem Prompt ist nicht unbedingt Code. Es kann genauso gut die Erkenntnis sein, dass eine einzelne HTML-Datei genügt oder dass du für den gewünschten Datenzugriff zuerst eine Freigabe brauchst. Beides verhindert, dass du an der falschen Stelle baust.

Dein Ideen-Backlog darf klein und persönlich sein

Notiere während einer normalen Woche jede Reibung kurz. Ein Satz pro Idee reicht: „Vor dem Monatsmeeting vergleiche ich vier Exporte“, „Ich suche zu oft dieselben Produktseiten“, „Meine Trainingsdaten liegen in drei Apps“. Bewerte die Liste nicht sofort.

Am Wochenende suchst du nicht die originellste Idee aus, sondern die mit dem klarsten Auslöser, Ablauf und Ergebnis. Baue dann einen Prototypen, der nur eine Frage beantwortet. Wenn er dir hilft, behältst und verbesserst du ihn. Wenn nicht, war er ein günstiger Test.

Die Projekte aus Folge 009 von Kontext.FM zeigen, wie unterschiedlich das aussehen kann: ein Reise-Globus, ein Quiz, ein Daten-Visualizer, ein Rechnungsabgleich oder ein kleiner Browser-Helfer. Gemeinsam ist ihnen nicht die Technologie. Gemeinsam ist, dass sie von einer echten Situation ausgehen und zunächst für genau die Menschen funktionieren müssen, die sie gebaut haben.