Zum Inhalt springen
Leitfaden6 Min. Lesezeit

Cursor mit einem Kunden teilen

Zeigen Sie einem Kunden den funktionierenden Build, ohne ihn einen Link öffnen zu lassen.

Geben Sie einem nicht-technischen Kunden den Beweis, dass ein Cursor-Build funktioniert, statt eines Links, den er nicht öffnen wird.

Ansehen, wie es funktioniertDie ersten 60 Sekunden Video sind kostenlos, mit Wasserzeichen. Bestätigen Sie Ihre E-Mail-Adresse, um es herunterzuladen.

Ein Kunde, der Arbeit an einem Cursor-Projekt in Auftrag gegeben hat, interessiert sich nicht für den Editor, die Sprache oder wie der Code organisiert ist. Er will wissen, ob die Sache, für die er bezahlt hat, erledigt ist. Ihm einen Link zu schicken verlangt von ihm, einer Adresse zu vertrauen, die er nie gesehen hat, sich durch eine ihm unbekannte Oberfläche zu navigieren und den relevanten Teil selbst zu finden. Ein kurzes Video beseitigt jeden dieser Schritte. Er drückt Play und sieht, wie die angeforderte Arbeit geschieht.

GogoScreen nimmt eine Webanwendungs-URL und einen einzeiligen Hinweis darauf, was gezeigt werden soll, entgegen und liefert ein erzähltes, geschnittenes MP4 mit Zooms auf Klicks, Cursor-Glättung, Schnitten toter Momente und eingebrannten Untertiteln. Speziell bei einem Cursor-Build gibt es davor einen Schritt: Die App muss zuerst irgendwo erreichbar bereitgestellt sein, da Cursor selbst keinen Vorschau-Link erzeugt. Sobald diese Bereitstellung existiert, funktioniert das Tool genauso wie mit jeder anderen URL.

Warum braucht eine Cursor-Übergabe einen zusätzlichen Schritt?

Bestätigen Sie, dass die Bereitstellung live und stabil ist, bevor Sie irgendetwas aufnehmen, das dem Kunden gezeigt wird. Eine Plattform, die mit einem automatischen Vorschau-Link ausgeliefert wird, macht diesen Schritt unsichtbar. Ein Cursor-Projekt nicht, er muss also bewusst gehandhabt werden, meist durch Bereitstellung auf dem Hosting, das das Team für das Projekt bereits nutzt, oder durch das eigens für die Übergabe eingerichtete Deployment. Tun Sie das vor dem Schreiben des Hinweises, nicht nebenbei, denn die Bereitstellung kann länger dauern als erwartet, wenn sie noch nicht vorher gemacht wurde.

Prüfen Sie, dass die Bereitstellung eine ist, die noch live sein wird, wenn der Kunde das Video tatsächlich ansieht, nicht eine temporäre Umgebung, die am nächsten Tag abgebaut wird. Ein Kunde, der eine Woche später mit einer Rückfrage kommt und den Link tot vorfindet, wird das als Beleg dafür lesen, dass die Arbeit nie wirklich fertig war, selbst wenn der aufgenommene Ablauf zum damaligen Zeitpunkt korrekt war.

Diese Übergabe unterscheidet sich vom Leitfaden zum Cursor-Portfolio-Demo, der für ein allgemeines Publikum geschrieben ist, das entscheidet, ob es sich lohnt, den Entwickler einzustellen, und vom Leitfaden zum Cursor-App-Prüfvideo, der für einen Prüfer geschrieben ist, der einen Build gegen ein schriftliches Briefing abgleicht. Eine Kundenübergabe liegt zwischen diesen beiden: Das Publikum hat die Arbeit bereits in Auftrag gegeben, die einzige offene Frage ist also, ob die konkret angeforderte Sache jetzt existiert und funktioniert.

Was der Kunde beurteiltWas ein roher Vorschau-Link von ihm verlangtWas das Video beseitigt
Ist die angeforderte Arbeit erledigtDurchklicken, navigieren, den relevanten Bildschirm findenEr sieht den genauen Ablauf abgeschlossen
Wirkt das vertrauenswürdigEine ihm unbekannte Adresse beurteilenNichts zum Klicken, nichts zum Hinterfragen
Passt das zum AuftragDie App mit seiner Erinnerung an das Briefing vergleichenDie Erzählung kann den Auftrag direkt benennen

Wie wählen Sie den zu zeigenden Ablauf?

Wählen Sie den einen Ablauf, der genau dem entspricht, worum der Kunde gebeten hat, nicht eine breitere Tour durch den Build. Gehen Sie zur ursprünglichen Anfrage zurück, nicht zum aktuellen Zustand des Codes. Wenn das Briefing ein Bestellformular verlangte, das eine Bestätigungs-E-Mail versendet, zeigen Sie genau das, abgeschlossen, statt einen breiteren Blick auf das dahinterliegende Admin-Panel. Ein Kunde, der das Video mit seiner Erinnerung an die Anfrage vergleicht, bemerkt es, wenn beide nicht zusammenpassen.

  • Bestätigen Sie die genaue Route, von der der angeforderte Ablauf startet.
  • Verwenden Sie plausible Beispieldaten statt leerer Tabellen oder Platzhaltertext.
  • Entfernen Sie vor der Aufnahme Informationen anderer Kunden aus der Umgebung.
  • Wenn ein Login den Ablauf blockiert, richten Sie ein Demokonto statt eines echten ein.

Weil Cursor-Builds eher echte Backend-Logik statt eines schnellen Mockups enthalten, zählt dieser Vorbereitungsschritt mehr, als er es bei einem leichten Prototyp würde. Testen Sie den Ablauf unmittelbar vor der Aufnahme von Hand, damit der im Video erfasste Zustand dem entspricht, was zuletzt als funktionierend bestätigt wurde.

Widerstehen Sie der Versuchung, mehr zu zeigen, als der Kunde verlangt hat, selbst wenn andere Teile des Builds zufällig fertig und beeindruckend sind. Ein Kunde, der einen Clip sieht, der vom umrissenen Auftrag in unzusammenhängendes Gebiet abdriftet, fragt sich vielleicht, ob die ursprüngliche Anfrage irgendwo im Prozess verlorenging. Wenn es zusätzliche fertige Arbeit gibt, die es wert ist, erwähnt zu werden, sprechen Sie sie getrennt an, nachdem der Kunde bestätigt hat, dass der angeforderte Ablauf genau das ist, was er wollte.

Wie gehen Sie mit einem echten Login für diese Aufnahme um?

Wenn ein Login den Ablauf blockiert, kann ein Demokonto über den genehmigten Prozess bereitgestellt werden, und bei GogoScreen werden die Zugangsdaten verschlüsselt, für genau einen Renderdurchlauf verwendet und danach gelöscht. Wird zuerst ein Storyboard geplant, bleiben die Zugangsdaten für diese Sitzung verschlüsselt und werden spätestens zwei Stunden nach ihrer letzten Verwendung gelöscht. Verwenden Sie dafür nicht das eigene Konto oder die Zugangsdaten des Kunden, selbst wenn das der schnellste Weg wäre, um genau die von ihm erwarteten Daten zu zeigen. Ein eigenes Demokonto hält den Aufnahmeprozess getrennt von jedem für irgendjemanden wichtigen Konto, und es bedeutet, dass sich der Kunde hinterher nie fragen muss, was mit seinem eigenen Login geschehen ist.

Schreiben Sie einen Hinweis, der Start, Aktion und Ergebnis benennt, und senden Sie dann die fertige Datei statt eines Links. Formulieren Sie ihn wo immer möglich in den eigenen Worten des Kunden, passend dazu, wie das ursprüngliche Briefing die Anfrage beschrieben hat, statt wie die Codebasis die Dinge intern zufällig benennt.

  1. Bestätigen Sie, dass die Bereitstellung live und stabil ist, bevor Sie irgendetwas aufnehmen, das dem Kunden gezeigt wird.
  2. Wählen Sie den einen Ablauf, der genau dem entspricht, worum der Kunde gebeten hat, nicht eine breitere Tour durch den Build.
  3. Schreiben Sie einen Hinweis, der Start, Aktion und Ergebnis benennt, und senden Sie dann die fertige Datei statt eines Links.

Was sollten Sie vor dem Versand prüfen?

Etwa einer von fünf Renderdurchläufen schlägt fehl oder muss wiederholt werden, beobachten Sie den Kandidaten also, bevor er den Kunden erreicht. Der Leitfaden zum README-Produktdemovideo ist hier ein nützlicher Vergleich, da beide Zielgruppen brauchen, dass das Video für sich allein steht, ohne eine separate Erklärung daneben zu benötigen. Wenn die App einen von Voiceover geprägten Erzählstil hat, behandelt der Leitfaden zum Voiceover für ein Produktdemovideo, wie sichergestellt wird, dass die Erzählung genau zum Ablauf passt, statt wie generischer Marketingtext zu klingen.

Wenn das Produkt des Kunden noch nicht gestartet ist, behandelt der Leitfaden zum Demovideo für eine SaaS-Warteliste einen verwandten Anwendungsfall zum Aufbau von Vorfreude, bevor die App vollständig öffentlich ist. Wenn der betreffende Build in v0 statt in Cursor gemacht wurde, behandelt der Leitfaden zum v0-App-Demovideo dieselbe Übergabedisziplin für ein Projekt mit einem anderen Ausgangspunkt. Für einen breiteren Launch-Kontext über einen einzelnen Kunden hinaus behandelt die KI-Agent-Launch-Checkliste die umfassendere Schrittfolge, die ein Launch meist braucht.

Für dieselbe Aufgabe bei anderen Cursor-Seiten siehe den Leitfaden zum Windsurf-Demovideo, den Leitfaden zum Windsurf-Landingpage-Video und den Leitfaden zum Windsurf-Product-Hunt-Launch-Video, die die entsprechende Übergabe für einen anderen KI-gestützten Editor behandeln. Für einen direkten Vergleich von Aufnahme-Tools siehe GogoScreen versus Demosmith. Beginnen Sie auf der Startseite für den URL- und Hinweis-Ablauf, durchsuchen Sie Leitfäden für den Rest der Reihe, prüfen Sie Vergleiche mit anderen Tools und sehen Sie sich die Preise an, bevor Sie einen Renderdurchlauf für einen Kunden einreichen.

Klarstellungen

Bevor Sie beginnen

Warum ist ein Video besser als ein Link für eine Cursor-Kundenübergabe?

Ein Kunde, der nicht oft Software baut, klickt selten auf einen unbekannten Link, und ein Cursor-Projekt hat ohnehin keine automatische Vorschau-URL, auf die man ihn verweisen könnte. Ein Video beseitigt beide Probleme, indem es die Arbeit direkt zeigt.

Muss der Kunde wissen, wie die App gebaut wurde?

Nein. Der Kunde beurteilt, ob die angeforderte Arbeit erledigt ist, nicht welcher Editor oder welches Tooling sie hervorgebracht hat. Halten Sie die Erzählung beim Ablauf, nicht beim Bauprozess.

Was, wenn die App einen echten Login braucht?

Verwenden Sie ein Wegwerf-Demokonto statt der eigenen Zugangsdaten des Kunden oder eines persönlichen Kontos. Bei GogoScreen werden bereitgestellte Zugangsdaten verschlüsselt, für genau einen Renderdurchlauf verwendet und danach gelöscht. Wird zuerst ein Storyboard geplant, bleiben die Zugangsdaten für diese Sitzung verschlüsselt und werden spätestens zwei Stunden nach ihrer letzten Verwendung gelöscht.

Fügen Sie eine URL ein, beschreiben Sie einen Ablauf und erhalten Sie ein Demovideo Ihrer Webanwendung.

Die ersten 60 Sekunden Video sind kostenlos, mit Wasserzeichen. Bestätigen Sie Ihre E-Mail-Adresse, um das Video herunterzuladen.