Cursor puede convertir una hoja de ventas en una aplicación. ¿Quién se encarga del enlace?
Cursor Live Apps ofrece alojamiento, autenticación y Postgres opcional. Un panel comercial y un portal de incorporación muestran dónde empieza el trabajo del equipo.
El lunes por la mañana, la responsable de ventas quiere ver en una sola página qué cuentas requieren atención. Los datos están en una hoja de cálculo, las reglas de asignación están en otra pestaña y cada persona tiene una copia ligeramente distinta. Un desarrollador puede montar un panel útil en una tarde. La primera pregunta incómoda llega cuando la responsable pide un enlace.
Anysphere, la empresa que desarrolla el entorno de programación Cursor, lanzó Live Apps el 5 de noviembre de 2026. Puedes pedirle a un agente de Cursor en la nube una aplicación web y Cursor puede configurar el alojamiento, la autenticación y, si hace falta, una base de datos Postgres. Tras una revisión de seguridad y una acción de publicación explícita, la aplicación obtiene una URL operativa. La función está disponible en planes de pago con los agentes en la nube activados. El código puede proceder de un repositorio nuevo o existente de Cursor Origin o GitHub. Anuncio de Cursor
Así, una aplicación interna se vuelve una opción práctica para procesos que antes dependían de copias de hojas de cálculo y mensajes semanales. También es fácil pasar de un prototipo a una herramienta de la que depende un compañero. Un panel comercial y un portal de incorporación muestran cómo decidir cuándo dar ese paso y averiguar quién puede ver, modificar o desactivar lo que la aplicación pone a disposición del equipo.
El botón de publicar cierra un trabajo y abre otro
Cursor te pide que indiques expresamente que quieres una aplicación y que uses un agente en la nube. Una sesión de programación local puede ayudar con el código, pero el flujo de Apps que describe Cursor pasa por el agente en la nube. Al empezar desde cero, se puede crear un repositorio en Cursor Origin. Si el equipo ya tiene una aplicación en un repositorio compatible, puedes reutilizar ese código. Cursor aprovisiona los recursos de la aplicación, mientras que quien la publica elige la URL y decide cuándo compartirla. Configuración y despliegue de Apps
Del código a una URL operativa, con el público y la fuente de datos por separado. Ilustración original de Telli.sh.
Cursor describe dos revisiones previas a la publicación. Las comprobaciones deterministas detectan condiciones conocidas, como un secreto escrito en un archivo. Una revisión de seguridad con IA examina el código en busca de problemas graves. Según Cursor, los administradores pueden añadir sus propias reglas, consultar las aplicaciones y secretos del equipo y retirar aplicaciones publicadas. También pueden autorizar algunas publicaciones bloqueadas por la revisión con IA. Cursor mantiene el bloqueo si hay código malicioso, secretos incrustados o credenciales expuestas. La persona responsable de la aplicación sigue decidiendo qué credenciales necesita. Anuncio de Cursor · Seguridad y administración de Apps
Imagina una aplicación cuya portada muestra los totales de ventas y cuyo punto de acceso a los detalles devuelve todas las cuentas. Al iniciar sesión como responsable comercial, la página puede parecer bien acotada. Aun así, otro compañero podría abrir una URL de detalle que haya adivinado o pedirle al servidor los datos de un territorio que no aparece en su tabla. La revisión del despliegue puede detectar fallos de implementación. La política de acceso del equipo sigue siendo la referencia para las reglas territoriales y las pruebas previas a la publicación deben comprobarlas con los roles pertinentes.
La URL operativa es el punto a partir del cual esas decisiones tienen consecuencias. Cuando los compañeros la guardan, un informe averiado puede retrasar una reunión matinal. Si la aplicación se convierte en el único lugar donde se registra una decisión o una aprobación, su base de datos pasa a formar parte de un proceso de negocio. Hasta una aplicación diminuta necesita a alguien capaz de explicar qué ocurrió cuando las cifras no cuadran.
Empieza con un panel de solo lectura
Supongamos que un equipo de operaciones comerciales quiere ver el embudo de ventas de dos territorios. Una primera versión razonable muestra cuántas oportunidades hay en cada etapa, la fecha de la última actualización y un enlace al registro del CRM para consultar los detalles. Primero funciona con cuentas ficticias. Cuando la vista sea correcta, sus credenciales pueden darle acceso de lectura a un informe acotado o a una vista de base de datos que solo incluya los campos pertinentes. El CRM sigue siendo responsable de las asignaciones y las notas. Así, la primera publicación deja fuera los cambios a los registros de negocio y conserva una referencia independiente para cotejar los totales.
La documentación de Apps de Cursor indica que los secretos de un almacén de datos u otro recurso externo se pueden introducir al configurar la aplicación o en el panel de Apps. Cursor afirma que el agente no ve sus valores. Las credenciales siguen siendo relevantes cuando la aplicación publicada hace una petición. Mantén la conexión en el código del servidor, restringe las consultas permitidas y revisa tanto la página generada como sus respuestas de red en busca de campos que debían permanecer en el servidor. Un secreto de solo lectura solo ayuda si la cuenta asociada tiene realmente acceso de solo lectura a los datos previstos. Secretos de Cursor Apps
| Decisión de la primera publicación | Panel del embudo comercial | Portal de incorporación |
|---|---|---|
| Público previsto | Grupo definido de operaciones comerciales | Empleados y coordinadores de incorporación invitados |
| Fuente oficial de datos | CRM o una vista de informes restringida | Guía interna aprobada y lista de incorporación |
| Estado útil de la aplicación | Filtros y preferencias de visualización | Pasos completados por el empleado que ha iniciado sesión |
| Comprobación antes de compartir | Comparar dos territorios e intentar abrir una URL de detalle sin autorización | Verificar que ningún empleado pueda leer o modificar la lista de otra persona |
| Responsable operativo | Operaciones comerciales, con una persona suplente | Operaciones de personal, con un responsable del contenido identificado |
Prueba el panel desde tres puntos de vista. El usuario previsto debe ver el total correcto y la hora de actualización. Un compañero de otro territorio debe ver solo las filas que permita la política de la aplicación, aunque edite el enlace o la petición. A quien no esté entre los destinatarios hay que denegarle el acceso antes de que reciba dato alguno del panel. La segunda comprobación es especialmente útil porque ese fallo pasa fácilmente inadvertido si solo prueba la aplicación quien la ha creado.
Coteja los resultados con una instantánea fija del sistema de referencia. Registra el intervalo de fechas, la zona horaria, las reglas de inclusión y el total exacto esperado para cada territorio. Si parece que faltan las oportunidades del lunes, quizá el gráfico esté interpretando de otra manera el intervalo del informe. Incluye en las primeras pruebas un resultado vacío, una petición al sistema de origen que agote el tiempo de espera y una actualización atrasada. Mostrar la última actualización correcta y un error explícito ayuda a distinguir una interrupción de una caída real en el embudo.
Un portal de incorporación justifica su base de datos campo a campo
Un portal que solo enlaza a políticas existentes puede prescindir de una base de datos nueva. Una lista interactiva añade datos que conservar. Cursor puede aprovisionar Postgres si la aplicación lo requiere, lo que facilita una segunda versión. Antes de aprovechar esa capacidad, anota qué valores deben guardarse. Quizá baste con un identificador del paso, la fecha y hora en que se completó y un identificador estable del usuario autenticado. Copiar notas de su responsable, un documento de identidad o el domicilio de un empleado añade riesgo sin mejorar la lista. Recursos de Cursor Apps
Separa los datos que ayudan a los empleados a seguir el proceso de los que necesita un coordinador para gestionarlo. Un empleado puede marcar su propia lectura obligatoria como completada. Un coordinador quizá necesite ver los pasos atrasados de todo un grupo. Aplica una regla de permisos distinta a la vista del coordinador y audita su consulta de forma independiente. Una sola pantalla de inicio de sesión da coherencia a ambas vistas, aunque sus necesidades de acceso sean diferentes.
Tres comprobaciones de acceso distintas para una misma aplicación interna. Ilustración original de Telli.sh.
Puedes probar la aplicación con un empleado ficticio y una cuenta de coordinador de pruebas antes de guardar información real. Define una prueba de acceso denegado que deba pasar para publicar. Un empleado no debe poder sobrescribir el estado de otro, aunque cambie un identificador en la petición del navegador. Después, comprueba que repetir la misma acción sobre un paso deje el mismo estado y no duplique el progreso. La prueba debe permitirte verificar el comportamiento sin pedirle a un compañero que exponga información real.
Para entregar una aplicación así conviene preparar una lista de traspaso. Anota cómo obtiene acceso un nuevo coordinador, dónde se modifica la guía, quién puede retirar el acceso a un exempleado y qué pasa con los registros que ya existen. Decide cómo recuperarás el estado necesario si un cambio falla. Cursor puede aprovisionar una base de datos. El equipo aún debe definir la recuperación y la conservación de datos para esta lista concreta.
Una invitación y una clave de integración cumplen funciones distintas
La documentación actual de Cursor Apps distingue tres opciones para compartir. Una aplicación por invitación puede abrirse a su responsable y a personas o grupos específicos que hayan iniciado sesión. Compartir con el equipo puede abrirla a todo el equipo de Cursor que haya iniciado sesión. Una aplicación pública puede abrirse a cualquiera que tenga la URL. En Teams y Enterprise, esta opción está desactivada por defecto salvo que la habilite un administrador. El anuncio del lanzamiento destaca el acceso público en los planes individuales. Por eso, una URL que funciona dice poco sobre el público efectivo hasta que compruebas la visibilidad en el panel de Apps. Opciones para compartir en Cursor Apps
La misma documentación explica el uso de claves de API para peticiones automatizadas. La clave se envía en una cabecera HTTP y la petición se identifica como automática, sin asociarse a una persona. Es práctico cuando un script necesita acceder a una aplicación. También cambia cómo investigas una petición inesperada. Si la aplicación admite tanto sesiones de personas como una clave de API, verifica que la automatización solo pueda ejecutar las acciones necesarias y registra dónde se usa la clave y quién la renovará. Si todas las acciones relevantes empiezan cuando alguien abre el enlace, limita la primera prueba a usuarios humanos. Claves de API de Cursor Apps
Cuando una aplicación lee de un almacén de datos, hay tres límites que probar. Cursor controla quién puede abrir el enlace. La aplicación decide a qué acciones y filas puede acceder ese público. El sistema de origen decide qué puede leer la credencial de servicio de la aplicación. Un error en un nivel puede quedar acotado por los demás. Si un panel interno solo necesita recuentos agregados del embudo, concederle una credencial capaz de consultar todos los registros del CRM encarece las consecuencias de un fallo pequeño.
Las pruebas pueden ser sencillas. Abre el enlace publicado en sesiones nuevas del navegador con una persona invitada, un compañero que haya iniciado sesión pero carezca de acceso y una persona que no haya iniciado sesión. En la sesión autorizada, solicita un registro que deba ser visible y otro de distinto territorio. Si un script usa una clave, asegúrate de que la petición falle sin la cabecera y de que se rechace una clave revocada. Son comprobaciones separadas porque cada una detecta un tipo de error distinto.
Acotar la primera versión agiliza la revisión
- Elige una tarea y un público bien definido. Para el panel, pide totales semanales del embudo por etapa, con registros ficticios, una hora de actualización visible y un enlace al CRM. Para el portal, pide una lista breve con cuentas de empleados ficticios.
- Inicia un agente en la nube y pídele explícitamente que construya una aplicación. Usa un repositorio al que pueda acceder la persona que se hará cargo. Mantén el primer cambio lo bastante pequeño para que esa persona pueda explicar las rutas, el modelo de datos y la gestión de errores.
- Especifica qué datos pueden persistir y qué peticiones pueden escribir. Conecta un secreto de alcance limitado en la configuración solo cuando el flujo con datos ficticios funcione. Pide al agente que muestre dónde se usa el secreto y dónde se aplican las comprobaciones de acceso.
- Usa la revisión previa a la publicación y lee lo que indica. Elige la URL, publica de forma explícita y comparte con el grupo adecuado más reducido. Prueba peticiones permitidas y denegadas en el enlace desplegado antes de que nadie dependa de él.
- Registra quién es responsable de la aplicación, con qué servicio de origen se comunica y quién puede retirarla. Repite una comprobación breve al cambiar la visibilidad, un conector o las credenciales. Conserva un enlace o un proceso alternativo para cuando la aplicación no esté disponible.
La primera publicación puede abarcar menos de lo que el agente es capaz de construir. Un panel que muestra una cifra fiable cada mañana puede ser más útil que un espacio con seis vistas cuyos cálculos nadie se pone de acuerdo en aceptar. Un portal de incorporación con una lista bien mantenida puede ahorrar mensajes repetidos, aunque la vista para coordinadores llegue más adelante. Una primera versión pequeña también permite que la persona a cargo observe qué cambios, solicitudes de acceso y dudas de soporte surgen de verdad.
Conviene evaluar el resultado durante una semana normal. Observa con qué frecuencia alguien abre la aplicación por iniciativa propia, si encuentra la fuente cuando cuestiona una cifra y cuánto tarda la persona a cargo en corregir un problema. Una aplicación que ahorra unos minutos al día puede justificar su existencia. Si el equipo aún recurre a la hoja de cálculo para confirmar los datos, averigua qué resultado le falta a la aplicación hacer fiable.
Los cambios de Cursor facilitan el inicio de esta clase de prueba. En el anuncio del 5 de noviembre, la construcción, la base de datos, la autenticación, el alojamiento y el enlace para compartir forman parte de un mismo flujo. Antes, el mismo experimento podía quedarse parado mientras alguien buscaba a quien se ocupara del alojamiento o intentaba configurar el inicio de sesión. Con esos elementos disponibles, el cuello de botella pasa a ser definir bien el público, los datos y las condiciones de publicación. El resultado útil es un enlace que alguien puede usar y del que otra persona sabe hacerse cargo. Anuncio de Cursor
Fuentes
- Lanzamiento de Cursor Live Apps, 5 de noviembre de 2026
- Documentación de Cursor Apps sobre configuración, uso compartido y controles de administración
Para conservar un registro consultable de las conversaciones y decisiones que hay detrás de una herramienta interna, crea una cuenta en Telli.sh.