firstdemand.io
Eine 4-stufige KI-Pipeline, die aus einer Landingpage-URL eine Demand-Strategie macht — Diagnose, Channel-Scorecard, 14-Tage-Playbook und fertige Copy — in unter zwei Minuten.
Was es macht.
firstdemand.io löst ein konkretes Problem: Technische Founder launchen eine Landingpage und stagnieren dann — weil sie nicht wissen, welche Early-Demand-Kanäle zu ihrem Produkt, ihrer ICP und ihrem Zeitbudget passen. Sie brauchen keinen weiteren SEO-Tool oder Marketing-Copiloten. Sie brauchen einen meinungsstarken Senior-Strategen, der ihre echte Produktseite liest und ihnen einen Plan gibt, den sie diese Woche umsetzen können.
Das Produkt ist kein Social-Scheduler, kein SEO-Tool, kein generischer Marketing-KI-Assistent. Eine Session. Unter zwei Minuten. Vier Deliverables.
Was reinkommt.
- Landingpage-URL — live gescraped, auch JS-gerenderte SPAs und Cloudflare-geschützte Seiten
- Strukturiertes Intake-Formular (vom AI aus dem Scrape vorausgefüllt): Produktbeschreibung, ICP, Launch-Phase, Ziele, Einschränkungen, Channel-Präferenzen
- Optional: Freitext-Korrektur, um die KI-Interpretation anzupassen
Vier Artefakte, eine Session.
Demand Readiness Diagnose
Readiness-Score 0–100, vier Signal-Bewertungen (Positioning / ICP / CTA / Social Proof), Haupt-Bottlenecks und ein Ready/Not-Ready-Urteil.
Channel Scorecard
Top-3-Kanäle nach Fit — mit Aufwand, Time-to-Signal, Tradeoffs und einem meinungsstarken "Warum nicht die anderen" für Rank 1.
14-Tage-Playbook
Tagesgruppiierter Aktionsplan mit konkreten Tasks, Zeitschätzung pro Task, und Copy, die auf der echten Produktsprache des Founders basiert.
Asset Pack
Copy-paste-fertig: Verzeichnis-Listings, Community-Posts, Outreach-Nachrichten, CTA-Varianten, Founder-Bio, Produkt-Oneliner — in einer von sechs Sprachen.
Die Pipeline.
Fünf Stufen, drei Modelle, zwei Anbieter. Jede Stufe streamt Ergebnisse per Server-Sent Events an den Client, sobald sie abgeschlossen ist.
Stufe 0 — URL-Scrape + Formular-Prefill
GPT-5.4 mit webSearchPreview crawlt die Live-URL — auch JS-gerenderte SPAs, Cloudflare-Schutz und React-Apps. Gibt ein einheitliches Schema zurück: Seitensignale UND Formular-Prefill in einem Aufruf. Dieser kombinierte Ansatz hat die Scrape-Latenz von ~40s (zwei sequenzielle Aufrufe) auf ~16-18s gesenkt.
Stufe 1 — Demand Readiness Diagnose
GPT-5.4 analysiert Positioning-Qualität, ICP-Klarheit, CTA-Stärke und Social Proof. Gibt eine strukturierte Diagnose mit einem Readiness-Score 0–100 zurück. Free-Nutzer erhalten diese Stufe plus Channel-Theme-Previews; die Pipeline stoppt an der Paywall.
Stufe 2 — Channel-Scoring
GPT-5.4 matcht ICP-Verhalten mit Channel-Fit über sechs Channel-Familien (Directories, Communities, Outreach, Partnerships, Monitoring, Public Posting). Die Channel-Familie ist ein Zod-Enum — das Modell kann nicht außerhalb davon halluzinieren.
Stufe 3 — 14-Tage-Playbook
Claude Opus 4-6 via OpenRouter. Gewählt wegen Instruction-Following bei komplexen tagesgruppierten Schemas und merklich stärkerer Copy-Qualität für sequenzielle Aktionspläne. Playbook-Aktionen referenzieren spezifische Produktsprache aus dem Scrape, nicht generische KI-Copy.
Stufe 4 — Asset Pack
Claude Opus 4-6 via OpenRouter. Copywriting-Qualität ist die Priorität. Alle Assets werden direkt in der gewünschten Ausgabesprache generiert — keine Übersetzungsschicht. Sechs Sprachen unterstützt; On-Demand-Regenerierung für weitere Sprachen ohne erneutes Durchlaufen der gesamten Pipeline.
OpenAI für analytische/Reasoning-Stufen. Anthropic für kreative/Copywriting-Stufen. Model-Assignments liegen in einer 14-Zeilen providers.ts — ein Modell wechseln ist ein Config-Change.
Was schwierig war.
Das Scrape-Latenz-Problem
Der ursprüngliche Scraper nutzte zwei sequenzielle LLM-Aufrufe: erst GPT-5.4 mit webSearchPreview zum Laden und Lesen der Seite (~25-30s), dann GPT-5-mini zur Synthese des Inhalts in Formular-Prefill-Werte (~10-15s). Gesamt: ~40s, bevor der Nutzer etwas sah.
Die Lösung: beide in einen einzigen generateText-Aufruf mit einem reichhaltigen Output-Schema (CombinedScrapeSchema) kombinieren, das Seitensignale und Formular-Prefill in einem Durchlauf abdeckt. Ergebnis: ~16-18s. Die zentrale Erkenntnis: das Schema so zu entwerfen, dass es zwei Zwecke gleichzeitig erfüllt, statt zwei fokussierte Aufrufe zu machen.
Checkpoint-Resumability vs. Idempotenz
Die Pipeline hat zwei überlappende Garantien: Idempotenz (wenn der Generate-Endpoint für ein fertiges Projekt erneut aufgerufen wird, werden gecachte Ergebnisse als SSE ohne Token-Kosten wiedergegeben) und Checkpoint-Resumability (wenn die Pipeline mittendrin abbricht, setzt der nächste Retry bei der letzten abgeschlossenen Stufe an).
Diese beiden Garantien interagieren auf nicht offensichtliche Weise — besonders rund um das justPurchased-Flag, das die Idempotenz umgeht, wenn der Nutzer gerade den Checkout abgeschlossen hat. Beide Muster sind notwendig für ein bezahltes Produkt mit teuren LLM-Aufrufen und unzuverlässiger serverloser Infrastruktur.
Prompt-Injection bei Nutzer-Korrekturen
Nutzer können Freitext-Korrekturen einreichen, um die KI-Interpretation ihres Produkts zu verfeinern. Diese Korrekturen werden in jeden nachfolgenden Prompt injiziert. Ein Founder kann versehentlich (oder absichtlich) Anweisungen schreiben, die das Modellverhalten überschreiben.
Der Sanitiser entfernt strukturelle Injektionsvektoren (Role-Override-Phrasen, Abschnitts-Delimiter, XML-Tags). Der injizierte Block ist als founder_note-XML-Tag gerahmt mit expliziter Anweisung, ihn als Daten, nicht als Anweisungen zu behandeln. Ein bewusster Kompromiss: zu viel Sanitisation entfernt legitimen Kontext; zu wenig öffnet das Modell für Manipulation.
URL-Level Shared Cache
Der Diagnose-Cache ist nach (normalizedUrl, Stage) mit einem 14-Tage-TTL gegliedert. Zwei verschiedene Nutzer, die dieselbe Landingpage analysieren, teilen dieselbe gecachte Diagnose — null zusätzliche LLM-Kosten. Nur Scorecard, Playbook und Assets sind personalisiert (und daher nicht nutzerübergreifend gecacht).
Wenn ein Nutzer eine Korrektur einreicht, wird der Cache für dieses Projekt vollständig umgangen. Das bedeutet: ein zahlender Nutzer, der einmal korrigiert hat, läuft immer durch frische LLM-Aufrufe, auch bei erneuten Durchläufen ohne weitere Änderungen. Dokumentierte bewusste Entscheidung.
In Zahlen.
6
LLM-Call-Sites in der Pipeline
3
verschiedene Modelle orchestriert
2
KI-Anbieter (OpenAI + Anthropic)
6
verschiedene Zod-Output-Schemas
~16s
Scrape-Latenz (KI-Pfad, aktuell)
~40s
Scrape-Latenz (ursprünglich, 2 Aufrufe)
60–90s
Pipeline-Gesamtlatenz (frisch, Pro)
<1s
Antwortzeit (Cache-Hit)
526
Zeilen in der Generation Route
9
DB-Schema-Migrationen
Was sich auf Kundenprojekte überträgt.
Die Engineering-Muster aus firstdemand.io sind direkt wiederverwendbar. Nicht theoretisch — in einem Live-Produkt battle-tested.
Output.object + Zod-Schemas
Jeder KI-Aufruf nutzt das Output.object-Muster des Vercel AI SDK mit einem ZodSchema. Das zwingt zur Schema-Gestaltung vor dem Prompt-Schreiben, was konsistent besser strukturierte Ausgaben produziert. Das SDK übernimmt automatisch Retries bei Parse-Fehlern.
Context-Builder-Muster
Prompt-Assemblierung ist in pure Functions ausgelagert (buildFounderContext, buildPageContext, buildCopyNotes, buildUserContextNote), die typisierte Objekte nehmen und formatierte String-Blöcke zurückgeben. Jeder Prompt komponiert diese Blöcke statt den vollständigen String inline zu konstruieren. Prompt-Änderungen bleiben lokalisiert.
Checkpoint + Idempotenz in Multi-Stage-Pipelines
Nach jeder Stufe eine partielle Ergebniszeile in die DB schreiben. Bei Retry die partielle Zeile erkennen und bei der letzten abgeschlossenen Stufe fortsetzen. Separate Idempotenz-Guard: wenn ein vollständiges Ergebnis existiert, als SSE wiedergeben ohne LLM-Aufrufe. Übertragbar auf jede mehrstufige KI-Pipeline mit teuren Schritten und erwarteten Fehlern.
Single-Call URL-Scrape + Synthese
Ein Live-Browsing-Tool anhängen (webSearchPreview), ein reichhaltiges Output-Schema definieren, das sowohl Extraktion als auch Synthese abdeckt, das Modell beides in einem Durchlauf füllen lassen. Senkt Latenz um ~60% gegenüber sequenziellen Aufrufen. Übertragbar auf jedes Produkt, das eine URL liest und strukturierte Daten extrahiert.