SaaS-Killer - App statt Abo

PROMPT SaaS-Killer - App statt Abo ------------------------ Wichtig, bevor du das Prompt kopierst: - Wenn du Wörter nicht verstehst, ist das kein Abbruchsignal. Frag den Agenten: „Erklär mir Repo, API-Key und Deployment so, dass ich entscheiden kann, ob ich das brauche.“ - Bau nicht sofort eine SaaS-App. Bau zuerst ein kleines Werkzeug für dich. - Die Leiter geht etwa so: Chat-Applet, lokale HTML-App, kleines Script, Browser Extension, Desktop-App, Web-App, App mit Login und Daten. - Jede Stufe hat mehr Möglichkeiten, aber auch mehr Stolperstellen. - Für den Anfang ist eine lokale Datei oft stark genug. - Ziel ist nicht, heute ein Produkt zu launchen. Ziel ist, heute etwas zu bauen, das funktioniert. ⚠️ Hinweis: Du kannst den Prompt auch zuerst in ChatGPT oder Claude stellen, weil dich dieser Chatbot wahrscheinlich besser kennt als eine frisch installierte Codex- oder Claude-App. Hänge dann an an den Prompt an: “WICHTIG: Arbeite nur die Planung durch und gib mir danach ein Prompt oder eine Datei, die ich an Codex oder Claude Code zur Umsetzung geben kann.” Nimm das Ergebnis und gib es an die Codex- oder Claude-App zur Umsetzung. ------------------------ Ich möchte ein kleines lokales Tool bauen, das mir echte Kosten spart. Erstelle dafür einen Plan und setze es dann um. Nutze alles, was du aus unseren bisherigen Interaktionen, meinem Arbeitsstil und meinen lokalen Projektdateien ableiten kannst. Wenn du keinen Zugriff auf solche Informationen hast oder zu wenig weißt, frage mich zuerst gezielt nach den Tools, Abos und wiederkehrenden Aufgaben, die ich nutze. Ziel: Finde ein SaaS-Tool oder einen wiederkehrenden bezahlten Workflow, den ich realistisch durch ein kleines lokales Tool, eine Mini-App, ein Script oder einen Agenten ersetzen kann. Arbeite in dieser Reihenfolge: 1. Kontext sammeln - Frage mich nach meinen bezahlten Tools, monatlichen Kosten, wichtigsten Workflows und nervigen Wiederholungsaufgaben, falls du diese Infos nicht sicher kennst. - Nutze vorhandene lokale Dateien, Notizen, Screenshots oder Projektordner nur read-only. - Erstelle eine kurze Liste möglicher Kandidaten. 2. Kandidaten bewerten Bewerte jeden Kandidaten nach: - monatlichem Sparpotenzial - Häufigkeit der Nutzung - technischer Einfachheit - Datenschutzrisiko - Wartungsaufwand - Wahrscheinlichkeit, dass ich innerhalb von 1 bis 2 Stunden ein Erfolgserlebnis bekomme 3. Beste Option auswählen Zeige mir die wichtigsten Optionen und empfehle mir daraus die beste. 4. Bestehende Repos prüfen Suche nach passenden GitHub-Repos, Templates oder Open-Source-Projekten, die wir dafür adaptieren können. Bevorzuge Repos, die: - aktiv gepflegt sind - klare Installation haben - wenig unnötige Komplexität mitbringen - lokal laufen können - zu meinem Betriebssystem passen Erfinde keine Repos. Wenn du keine guten findest, plane einen kleinen Neubau. 5. Personalisierung einplanen Die Lösung soll zu mir passen: - Sprache der App: meine Sprache - Ton: so, wie ich arbeite und angesprochen werden möchte - Design: einfache Oberfläche, passende Farben, keine generische Demo-Optik, modernes responsive Design - Defaults: so wählen, dass ich möglichst wenig konfigurieren muss - Ausgabeformate: so, dass ich sie direkt in meinem Alltag verwenden kann 6. Erst planen, dann bauen Baue noch nichts. Erstelle zuerst eine detaillierte Datei PLAN.md mit allen relevanten Details. 7. Umsetzung vorbereiten Erstelle zusätzlich TASKS.md mit passenden Phasen, zum Beispiel: - Phase 1: lauffähiger Mini-Prototyp - Phase 2: echte Beispieldaten zum Testen - Phase 3: kleine Oberfläche oder Bedienung verbessern - Phase 4: Export, Speicherung oder Automatisierung - Phase 5: Entscheidung: behalten, verbessern oder Abo weiterzahlen Jede Phase muss am Ende einen Test enthalten, den du selbst ausführen kannst. Wichtig: - Arbeite token-effizient. - Lies nur Dateien, die du wirklich brauchst. - Vermeide große Frameworks, wenn ein kleines Script reicht. - Nutze vorhandene Repos, wenn sie Zeit sparen. - Frage mich nicht nach Designentscheidungen, die du vernünftig selbst treffen kannst. - Keine API-Keys in Code schreiben. - Keine Dateien löschen. - Keine Veröffentlichung ins Internet, solange ich das nicht ausdrücklich sage. Starte jetzt mit Kontextfragen oder mit der Analyse, wenn du schon genug weißt.