Aus der Vertriebstabelle wird eine Live-App. Wem gehört der Link?

Am Montagmorgen möchte die Vertriebsleitung auf einer Seite sehen, welche Kunden Aufmerksamkeit brauchen. Die Zahlen stehen in einer Tabelle, die Regeln für die Zuständigkeit in einem zweiten Tabellenblatt. Im Team sind leicht unterschiedliche Kopien im Umlauf. Ein Entwickler kann an einem Nachmittag ein brauchbares Dashboard bauen. Die erste unangenehme Frage kommt, wenn die Vertriebsleitung nach dem Link fragt.

Anysphere, der Hersteller der Programmierumgebung Cursor, hat Live Apps am 5. November 2026 veröffentlicht. Ein Cursor-Cloud-Agent kann auf Anfrage eine Web-App erstellen. Cursor stellt das Hosting, die Anmeldung und bei Bedarf eine Postgres-Datenbank bereit. Nach einer Sicherheitsprüfung und einem ausdrücklichen Veröffentlichungsschritt erhält die App eine erreichbare URL. Die Funktion ist in kostenpflichtigen Tarifen mit aktivierten Cloud-Agenten verfügbar. Der Code kann aus einem neuen oder bestehenden Repository bei Cursor Origin oder GitHub stammen. Veröffentlichungsmeldung von Cursor

Damit kommen interne Apps auch für Abläufe infrage, die bisher über Tabellenkopien und wöchentliche Nachrichten organisiert wurden. Zugleich ist der Schritt vom Prototyp zu einem Werkzeug, auf das sich jemand verlässt, schnell getan. An einem Vertriebsdashboard und einem Onboarding-Portal lässt sich zeigen, wann ein Prototyp dafür bereit ist und wer die Inhalte einsehen, ändern oder den Zugriff darauf abschalten kann.

Mit dem Bereitstellen endet eine Aufgabe und beginnt die nächste

Laut Cursor soll der Auftrag ausdrücklich eine App verlangen und an einen Cloud-Agenten gehen. Eine lokale Programmiersitzung kann bei der Arbeit am Quellcode helfen, der beschriebene Apps-Ablauf läuft über den Cloud-Agenten. Bei einem neuen Projekt kann ein Repository auf Cursor Origin entstehen. Hat das Team bereits eine App in einem unterstützten Repository, kann es diesen Quellcode verwenden. Cursor stellt die Ressourcen bereit, die veröffentlichende Person wählt die URL und entscheidet, wann sie den Link teilt. Apps einrichten und bereitstellen

Der Weg vom Quellcode zur Live-URL. Nutzerkreis und Datenquelle sind getrennt dargestellt. Eigene Illustration von Telli.sh.

Cursor beschreibt zwei Prüfungen vor der Veröffentlichung. Fest definierte Regeln erkennen bekannte Probleme wie einen offen in einer Datei abgelegten Zugangsschlüssel. Eine KI-Sicherheitsprüfung untersucht den Quellcode der App auf schwerwiegende Mängel. Laut Cursor können Teamadministratoren eigene Regeln ergänzen, Apps und hinterlegte Geheimnisse ihres Teams einsehen und Apps aus dem Verkehr ziehen. Sie können auch bestimmte Veröffentlichungen genehmigen, die bei der KI-Prüfung blockiert wurden. Bei bösartigem Code, fest im Code hinterlegten Geheimnissen oder offengelegten Zugangsdaten bleibt die Sperre bestehen. Welche Zugangsdaten die App überhaupt braucht, entscheidet weiterhin ihr Verantwortlicher. Veröffentlichungsmeldung von Cursor · Sicherheit und Administration für Apps

Stellen Sie sich eine App vor, deren Startseite Vertriebszahlen zusammenfasst, während ein Detailendpunkt sämtliche Kunden zurückgibt. Für eine angemeldete Vertriebsleiterin mag die Anzeige wie vorgesehen eingeschränkt aussehen. Jemand aus dem Team könnte dennoch eine erratene Detail-URL öffnen oder beim Backend Daten für ein Vertriebsgebiet abfragen, das in der Tabelle nicht angezeigt wird. Die Bereitstellungsprüfung kann Mängel der Umsetzung aufdecken. Welche Gebiete für wen freigegeben sind, ergibt sich aus der Zugriffsrichtlinie des Teams. Die Freigabeprüfung muss deshalb die tatsächlichen Rollen abdecken.

Sobald die Live-URL im Umlauf ist, haben diese Entscheidungen Folgen. Haben Kollegen ein Lesezeichen gesetzt, kann ein fehlerhafter Bericht die morgendliche Besprechung aufhalten. Ist die App der einzige Ort, an dem eine Entscheidung oder Freigabe festgehalten wird, gehört ihre Datenbank zum Geschäftsprozess. Selbst eine kleine App braucht jemanden, der falsche Zahlen erklären kann.

Beginnen Sie mit einem Dashboard, das nur lesen kann

Ein Sales-Ops-Team möchte beispielsweise den Stand seiner Pipeline für zwei Gebiete einsehen. Eine sinnvolle erste App zeigt die Zahl der Verkaufschancen nach Phase, den Zeitpunkt der letzten Aktualisierung und einen Link zum CRM-Datensatz für Einzelheiten. Zunächst arbeitet sie mit fiktiven Kunden. Sobald die Anzeige stimmt, kann das App-Konto auf einen eingeschränkten Bericht oder eine Datenbankansicht zugreifen, die nur die vorgesehenen Felder enthält. Zuweisungen und Notizen bleiben im CRM. So schreibt die erste Version keine Änderungen in die Geschäftsdaten, und die angezeigten Summen lassen sich gegen eine unabhängige Quelle prüfen.

Laut der Apps-Dokumentation können Zugangsdaten für ein Data Warehouse oder eine andere externe Ressource bei der Einrichtung oder im Apps-Dashboard hinterlegt werden. Cursor zufolge sieht der Agent die Werte nicht. Relevant werden sie wieder, wenn die veröffentlichte App eine Anfrage ausführt. Halten Sie die Verbindung im serverseitigen Code und begrenzen Sie den Umfang der Abfragen. Prüfen Sie die fertige Seite und ihre Netzwerkantworten auf Felder, die beim Server hätten bleiben sollen. Ein als schreibgeschützt bezeichnetes Geheimnis hilft nur, wenn das hinterlegte Konto für die vorgesehenen Daten tatsächlich ausschließlich Leserechte besitzt. Geheimnisse in Cursor Apps

Prüfen Sie das Dashboard aus drei Blickwinkeln. Die vorgesehene Person sollte die richtige Summe und den letzten Aktualisierungszeitpunkt sehen. Für einen Kollegen aus einem anderen Gebiet dürfen selbst bei einem bearbeiteten Link oder einer manipulierten Anfrage nur die laut App-Richtlinie erlaubten Zeilen erscheinen. Wer außerhalb des Freigabekreises liegt, sollte abgewiesen werden, bevor Dashboard-Daten übertragen werden. Die zweite Prüfung ist besonders wertvoll, weil der Fehler leicht verborgen bleibt, wenn nur der Entwickler testet.

Gleichen Sie die Angaben anhand eines festen Datenstands aus dem maßgeblichen System ab. Notieren Sie Zeitraum, Zeitzone, Einschlussregeln und die genaue Sollsumme pro Gebiet. Wenn montags Verkaufschancen in der Grafik fehlen, kann das auch an einer anderen Auslegung des Berichtszeitraums liegen. Testen Sie früh ein leeres Ergebnis, eine Zeitüberschreitung im Quellsystem und eine veraltete Aktualisierung. Wer die letzte erfolgreiche Aktualisierung und eine verständliche Fehlermeldung sieht, kann einen Ausfall von einem echten Rückgang in der Pipeline unterscheiden.

Ein Onboarding-Portal braucht eine Datenbank für konkrete Felder

Ein Portal, das nur auf bestehende Richtlinien verlinkt, kommt möglicherweise ohne neue Datenbank aus. Eine interaktive Checkliste erzeugt dagegen einen Zustand. Cursor kann bei Bedarf Postgres bereitstellen, sodass die zweite Version einfach zu bauen ist. Schreiben Sie vorher auf, welche Werte tatsächlich gespeichert werden müssen. Die Kennung des Checklistenpunkts, der Zeitpunkt des Abschlusses und eine stabile Kennung der angemeldeten Person können genügen. Kopien von Führungsnotizen, Ausweisnummern oder Privatadressen erhöhen das Risiko, ohne die Checkliste nützlicher zu machen. Ressourcen von Cursor Apps

Trennen Sie die Daten, die Mitarbeitende durch den Ablauf führen, von den Daten, die eine zuständige Person zur Koordination braucht. Mitarbeitende können ihre eigene Pflichtlektüre als abgeschlossen markieren. Die Koordination muss unter Umständen verspätete Schritte für eine ganze Gruppe sehen. Geben Sie dieser Ansicht eine eigene Berechtigungsregel und prüfen Sie ihre Abfrage separat. Eine gemeinsame Anmeldemaske sorgt für einheitliches Aussehen, während die Zugriffsanforderungen unterschiedlich bleiben.

Drei unterschiedliche Zugriffsprüfungen für dieselbe interne App. Eigene Illustration von Telli.sh.

Vor dem Speichern echter Onboarding-Daten reicht ein Pilot mit einer fiktiven Person und einem Testkonto für die Koordination. Formulieren Sie ein eindeutiges Negativkriterium für die Freigabe. Ein Mitarbeiter darf den Erledigungsstatus einer anderen Person auch dann nicht überschreiben können, wenn er eine Kennung in der Browseranfrage ändert. Prüfen Sie danach, ob ein zweiter Versuch für denselben Schritt denselben Zustand ergibt, ohne einen doppelten Fortschrittseintrag anzulegen. So lässt sich das Verhalten prüfen, ohne dass jemand echte Informationen preisgeben muss.

Für eine solche App lohnt sich eine Übergabecheckliste. Halten Sie fest, wie neue Verantwortliche Zugang erhalten, wo der Leitfaden gepflegt wird, wer den Zugriff ausgeschiedener Mitarbeitender entfernen kann und was mit bestehenden Erledigungsnachweisen passiert. Klären Sie, wie der erforderliche Datenstand bei einer fehlgeschlagenen Änderung wiederhergestellt werden kann. Cursor kann eine Datenbank bereitstellen. Was Wiederherstellung und Aufbewahrung für diese Checkliste konkret bedeuten, muss das Team festlegen.

Einladungen und Integrationsschlüssel erfüllen unterschiedliche Aufgaben

Die aktuelle Apps-Dokumentation von Cursor unterscheidet drei Freigabeoptionen. Eine App nur für Eingeladene kann der Eigentümer öffnen. Zugelassene Personen oder Gruppen erhalten nach der Anmeldung ebenfalls Zugang. Eine Teamfreigabe kann das ganze angemeldete Cursor-Team einschließen. Bei einer öffentlichen App reicht die URL. In Teams- und Enterprise-Tarifen ist die öffentliche Freigabe standardmäßig deaktiviert, bis ein Administrator sie erlaubt. Die Meldung zur Einführung hebt die öffentliche Freigabe bei Einzeltarifen hervor. Eine funktionierende URL verrät daher wenig über den tatsächlichen Nutzerkreis, solange Sie die Sichtbarkeit im Apps-Dashboard nicht geprüft haben. Freigaben in Cursor Apps

Dieselbe Dokumentation beschreibt API-Schlüssel für automatisierte Anfragen. Der Schlüssel wird im HTTP-Header mitgesendet und die Anfrage als automatisiert gekennzeichnet, ohne Zuordnung zu einer Person. Das hilft, wenn ein Skript die App aufrufen soll. Die Untersuchung einer unerwarteten Anfrage läuft dann anders. Wenn die App persönliche Sitzungen und einen API-Schlüssel unterstützt, prüfen Sie die Berechtigungen der Automatisierung. Dokumentieren Sie, wo der Schlüssel eingesetzt wird und wer ihn austauscht. Beginnt jede relevante Aktion damit, dass jemand aus dem Team den Link öffnet, können im ersten Pilotversuch persönliche Anmeldungen ausreichen. API-Schlüssel in Cursor Apps

Wenn eine App ein Data Warehouse abfragt, gibt es drei Grenzen zu prüfen. Cursor bestimmt den Nutzerkreis für den Link. Die App entscheidet, welche Aktionen und Datenzeilen diesem Kreis offenstehen. Das Quellsystem legt fest, was das Dienstkonto der App lesen kann. Die anderen Ebenen können die Auswirkungen eines Fehlers an einer Stelle begrenzen. Braucht ein internes Dashboard nur aggregierte Pipeline-Zahlen, kann eine Berechtigung für sämtliche CRM-Datensätze aus einem kleinen App-Fehler ein teures Problem machen.

Die Prüfungen können einfach sein. Öffnen Sie den Live-Link in einer frischen Browsersitzung als eingeladene Person, als angemeldetes Teammitglied ohne Berechtigung und ohne Anmeldung. Rufen Sie im berechtigten Fall einen erlaubten Datensatz und einen aus einem anderen Gebiet ab. Verwendet ein Skript einen Schlüssel, prüfen Sie, ob die Anfrage ohne den zugehörigen Header scheitert und ein gesperrter Schlüssel abgewiesen wird. Die getrennten Prüfungen zeigen unterschiedliche Fehlerarten.

Eine eng begrenzte erste Version lässt sich schneller prüfen

1. Wählen Sie eine Aufgabe und einen klar benannten Nutzerkreis. Für das Dashboard reichen wöchentliche Pipeline-Zahlen je Phase mit Testdaten, sichtbarem Aktualisierungszeitpunkt und einem Link zurück ins CRM. Für ein Portal eignet sich eine kleine Checkliste mit fiktiven Mitarbeiterkonten.
2. Starten Sie einen Cloud-Agenten und beauftragen Sie ihn ausdrücklich mit einer App. Verwenden Sie ein Repository, auf das die spätere verantwortliche Person Zugriff hat. Halten Sie die erste Codeänderung klein genug, damit sie Routen, Datenmodell und Fehlerbehandlung erklären kann.
3. Legen Sie fest, welche Daten gespeichert werden und welche Anfragen schreiben dürfen. Hinterlegen Sie ein eng begrenztes Geheimnis erst dann in den App-Einstellungen, wenn der Ablauf mit Testdaten funktioniert. Lassen Sie sich zeigen, wo die Zugangsdaten verwendet werden und wo die Prüfungen für den Nutzerkreis greifen.
4. Starten Sie die Veröffentlichungsprüfung und sehen Sie sich deren Ergebnisse an. Wählen Sie die URL, veröffentlichen Sie ausdrücklich und teilen Sie sie mit dem kleinsten geeigneten Kreis. Testen Sie zulässige und abzuweisende Anfragen am bereitgestellten Link, bevor jemand darauf angewiesen ist.
5. Dokumentieren Sie, wer die App betreibt, welches Quellsystem sie anspricht und wer sie abschalten kann. Wiederholen Sie eine kurze Prüfung nach Änderungen an Sichtbarkeit, Verbindung oder Zugangsdaten. Halten Sie einen Ersatzlink oder Ausweichprozess für einen vorübergehenden Ausfall bereit.

Die erste Version kann kleiner bleiben als das, was der Agent bauen könnte. Ein Dashboard, das jeden Morgen eine verlässliche Zahl liefert, kann nützlicher sein als sechs Ansichten, über deren Berechnungen gestritten wird. Ein Onboarding-Portal mit gut gepflegter Checkliste kann wiederholte Nachfragen vermeiden, auch wenn die Koordinationsansicht später kommt. Bei einer kleineren Version kann die verantwortliche Person leichter beobachten, welche Änderungen, Zugangsanfragen und Supportfragen wirklich anfallen.

Beurteilen Sie das Ergebnis im Lauf einer gewöhnlichen Woche. Beobachten Sie, wie oft jemand die App von sich aus öffnet, ob sich bei einem fraglichen Wert die Quelle finden lässt und wie lange die Behebung eines Fehlers dauert. Eine App, die täglich ein paar Minuten spart, kann sich lohnen. Wenn die Tabelle weiter zur Bestätigung dient, finden Sie heraus, welcher Wert in der App noch nicht als verlässlich gilt.

Die Änderungen von Cursor erleichtern den Einstieg in einen solchen Versuch. In der Ankündigung vom 5. November gehören Erstellung, Datenbank, Anmeldung, Hosting und Freigabelink zum selben Ablauf. Früher konnte das Vorhaben schon scheitern, während jemand eine verantwortliche Person für das Hosting suchte oder eine Anmeldung organisieren wollte. Sind diese Bausteine verfügbar, kommt es darauf an, Nutzerkreis, Daten und Freigabebedingungen klar zu erklären. Am Ende steht ein Link, den jemand nutzen kann und für den sich eine andere Person verantwortlich weiß. Veröffentlichungsmeldung von Cursor

Quellen

• Cursor Live Apps, Veröffentlichung am 5. November 2026
• Dokumentation zu Cursor Apps mit Einrichtung, Freigabe und Administration

---

Wenn Sie Gespräche und Entscheidungen hinter einem internen Werkzeug durchsuchbar festhalten möchten, erstellen Sie ein Telli.sh-Konto.