Cursor Build Live Apps: un tablero de reseñas de la competencia por menos de 1 céntimo al día

Cursor lanzó Build Live Apps el 5 de noviembre de 2026 (2026-11-05). Dentro de un agente en la nube basta con decir «build an app» para que Cursor construya una aplicación web, añada Postgres si hace falta, configure el inicio de sesión de Cursor, la aloje y devuelva un enlace.

Con su documentación diseñamos un tablero de reseñas de la competencia para un equipo de tres personas en Madrid que prepara una app de finanzas personales. Cada mañana, el tablero descarga las reseñas más recientes de Fintonic en App Store, Google Play y Trustpilot, y como referencia las de Monarch en Estados Unidos, junto con los mensajes de Reddit que comparan YNAB y Monarch. El servidor solo llama a POST /api/v1/social de EveryInfra; la clave vive en un secreto de equipo de Cursor y el código solo lee el nombre de la variable, de modo que ni el navegador ni el agente ven su valor.

La parte de Cursor no la ejecutamos, así que las instrucciones, la ruta de refresco y el disparador diario son ejemplos de configuración. La parte de datos sí la llamamos de verdad la noche del 13 de noviembre de 2026 (2026-11-13), en tres momentos: 21:31, 22:14 y 22:36, hora de Singapur. En la prueba añadimos YNAB en las tres tiendas como segunda referencia estadounidense.

Primera: un refresco diario hace 7 llamadas y cuesta 0,009126 USD a precio de catálogo, unos 0,27 USD cada 30 días, menos del 1 % de un asiento Premium de Cursor. Segunda: las 30 reseñas más recientes de App Store no cambiaron en ninguna ronda, y la más nueva de Fintonic ya tenía entre 66,5 y 67,2 horas; como las tiendas publican las reseñas con uno o dos días de retraso, refrescar cada hora solo multiplica la factura por 24. Tercera: Google Play y Trustpilot respondieron 503 en las dos primeras rondas, no se cobró nada y el reintento de la tercera ronda funcionó; el tablero tiene que guardar la hora del último refresco correcto de cada fuente para que una fuente sin actualizar no arrastre a las demás. La tercera ronda dejó además otro dato: en Google Play en español, 34 de las 40 reseñas recientes de Fintonic son de 1 o 2 estrellas, y Fintonic contestó a las 40.

Qué es Cursor Build Live Apps

Cursor publicó Build Live Apps el 5 de noviembre de 2026. La entrada del changelog parte de una idea sencilla: los agentes han abaratado mucho escribir código, pero la mayoría de las aplicaciones que la gente construye nunca salen de localhost. El lanzamiento mete ese último paso dentro de Cursor. Describes la aplicación y Cursor la construye, prepara una base de datos, configura el inicio de sesión, la despliega y te devuelve un enlace. La documentación la recoge dentro de Cloud Agents, en la página de Apps.

La función solo existe en el agente en la nube. La documentación lo dice sin rodeos: hay que usar un cloud agent, porque en local no está soportada. Un cloud agent es un agente de programación que trabaja en su propia máquina virtual en la nube de Cursor, con un entorno de desarrollo completo, según la documentación de Cloud Agents. Se puede lanzar desde la aplicación de escritorio, la web, la app de iOS, Slack, un comentario de GitHub, Linear o la API. En la práctica, una responsable de producto puede escribir el encargo desde el móvil y el agente construye, previsualiza y publica la aplicación sin que nadie abra un portátil.

El cambio grande respecto a agosto es el alojamiento. El 27 de agosto de 2026 Cursor lanzó Start from scratch, que ya podía publicar en una URL real, pero exigía una cuenta de Vercel. El lanzamiento de noviembre elimina ese paso. La documentación de Apps explica que Cursor crea una cuenta de alojamiento dedicada para cada equipo, o para cada persona en un plan individual, aislada del resto de equipos y usuarios.

The New Stack contó el 5 de noviembre que Vercel dijo en X que la función funciona sobre Vercel for Platforms. La documentación de Cursor no nombra ninguna empresa de alojamiento, así que en este artículo usamos su fórmula: alojado por Cursor. Para un tablero de reseñas importa menos quién aloja y más tres cosas: dónde viven los secretos, quién puede abrir la aplicación y cómo se actualizan los datos.

Estas son las partes de la documentación que afectan a un tablero de reseñas de la competencia:

Hay cosas que la documentación no dice y conviene no suponerlas. No indica la región del alojamiento, ni el tamaño máximo de Postgres, ni la política de copias de seguridad. Tampoco menciona un programador de tareas propio para las apps. Sin programador propio, el disparador diario hay que ponerlo aparte; la sección sobre el refresco compara tres formas de hacerlo.

Para un equipo en España hay un detalle práctico más. Ni la página de Apps ni el changelog hablan de dónde se guardan los datos. Si el tablero solo contiene reseñas públicas y notas internas sin datos de clientes, eso no plantea problemas. Si alguien quiere cruzar las reseñas con datos de sus propios usuarios, esa parte debería vivir en la infraestructura habitual del equipo, no en una app generada en una tarde.

Quién puede usarlo y cuánto cuesta

La página de precios de Cursor, leída el 13 de noviembre de 2026, muestra cinco niveles individuales: Free a 0 USD, Plus a 8 USD al mes, un nivel de 30 USD, Super a 100 USD y Ultra a 200 USD. La tarjeta de 30 USD no lleva nombre visible, pero la de Super dice «Everything in Premium», así que ese nivel es Premium. «Cloud agents & automations» aparece por primera vez en la lista de funciones justo en ese escalón.

La sección de problemas frecuentes de Cloud Agents es más directa: hace falta un plan que incluya agentes en la nube, es decir, Premium o superior, Teams, Enterprise o un plan de pago antiguo. Free y Plus no los incluyen. El changelog lo resume como «disponible en todos los planes de pago con cloud agents activados». Leídas juntas, ambas fuentes sitúan la entrada en Premium.

La cuota del plan no es todo el gasto. La sección de facturación de Cloud Agents explica que los agentes en la nube consumen el uso del plan a la tarifa del modelo elegido, y que la primera vez Cursor pide fijar un límite de gasto. La página de precios añade que el uso de modelos de terceros no entra en la cuota mensual y se factura aparte.

Por tanto, lo que cuesta construir el tablero en modelo depende de cuántas rondas le pidas al agente y de qué modelo uses. No ejecutamos el agente dentro de Cursor, así que no damos cifra para esa parte. Lo que sí es seguro es que, una vez publicado, el refresco diario es código de servidor normal que llama a una API, sin modelo de por medio, y no añade gasto de modelo.

Para un equipo de tres a cinco personas basta con un asiento Premium para construir y publicar. Si otras personas tienen que abrir el tablero, hay dos caminos: pasar a Teams, para que todo el mundo entre con su cuenta de Cursor, o quedarse en un plan individual y compartir el enlace en público. Las reseñas públicas no son datos privados, así que un tablero público es técnicamente posible. Aun así, un tablero suele acabar con notas y decisiones internas, y por eso lo dejamos detrás del inicio de sesión.

Las tres preguntas que debe contestar el tablero

Pongamos un equipo concreto. Tres personas en Madrid construyen una app de finanzas personales para el mercado español. Su competidor local es Fintonic, una app española de control de gastos. Además miran a YNAB y Monarch, dos apps de presupuesto de Estados Unidos que los usuarios comparan a menudo en Reddit y que suelen estrenar antes las funciones nuevas del sector. El mercado se movió mucho en las últimas cuatro semanas, y casi todo vino de fuera.

El 21 de octubre de 2026 Monarch reabrió su conector MCP, para que sus usuarios pregunten a Claude, ChatGPT o Cursor por sus propios datos de presupuesto. El 5 de noviembre Anthropic lanzó Personal Finance en Claude, una beta para usuarios Pro, Max y Ultra en Estados Unidos que conecta cuentas bancarias a través de Plaid con acceso de solo lectura. El 4 de noviembre Apple abrió los mensajes de retención para suscripciones con renovación automática. Ver a diario cómo reaccionan los usuarios de la competencia sirve más que una encuesta mensual.

Le dimos al tablero tres preguntas, y cada una tiene sus datos. Primera: de qué se quejan las reseñas recientes de 1 y 2 estrellas de cada competidor. Los datos son las reseñas más nuevas de App Store y Google Play, agrupadas por estrellas y por tema. Segunda: si cada competidor se ve igual en sitios distintos. Las reseñas de las tiendas vienen sobre todo del móvil, mientras que en Trustpilot abundan los textos largos sobre cobros, devoluciones y atención al cliente.

Tercera: hacia dónde se mueven los usuarios. En Reddit, mensajes como «me he pasado de YNAB a Monarch» o «busco una alternativa a YNAB» enseñan el movimiento antes de que cambie la nota media. Estas tres preguntas limitan el alcance a cuatro capacidades y fijan también el ritmo de actualización. Las reseñas y los mensajes no cambian minuto a minuto, así que con un refresco al día basta. Más adelante calculamos el coste diario de la API a partir de llamadas reales.

Cuatro capacidades en una tabla

Las cuatro capacidades usan el mismo endpoint de EveryInfra, POST /api/v1/social; solo cambian platform, action y params. Los parámetros, precios, límites y campos de la tabla salen del catálogo gratuito de EveryInfra, leído el 13 de noviembre de 2026 a las 21:30, hora de Singapur (14:30 en Madrid).

El catálogo también deja claros algunos detalles de parámetros que es fácil equivocar. En App Store, app_id es el número que aparece en el enlace de la tienda, no un bundle id del tipo com.ejemplo.app; para Fintonic es 672220319 y, para leer las reseñas españolas, hay que pasar country: es. Google Play es al revés: pide el nombre del paquete, com.fintonic, y no admite pegar la URL completa. Además, según el catálogo, las reseñas de Google Play cambian con language y no con el país: con el mismo idioma, dos países distintos devuelven las mismas reseñas.

Trustpilot pide el dominio de la empresa, en este caso fintonic.com, y su filtro date solo acepta valores fijos como last7days o last30days. La búsqueda de Reddit cubre siempre el último mes y solo devuelve mensajes en los que la palabra aparece en el título o en el cuerpo. Si no hay coincidencias, la llamada cuenta como resultado vacío y se devuelve el importe.

Las páginas de plataforma reúnen todas las capacidades de cada sitio: App Store Scraper API, Google Play Scraper API, Trustpilot Scraper API y Reddit Scraper API.

El recorrido de los datos: el navegador solo habla con la app y la clave se queda en el servidor

Empecemos por el camino que siguen los datos. Con el tablero publicado, una persona del equipo abre la app que aloja Cursor; primero pasa por el inicio de sesión de Cursor. La página solo pide datos al servidor de la propia app, y ese servidor lee de Postgres las reseñas ya guardadas. Una petición diaria lanza el refresco: llega con una API key de Cursor a la ruta de actualización, que lee la clave de EveryInfra de una variable de entorno del servidor y llama una vez a cada capacidad.

Después, la ruta escribe en Postgres las reseñas nuevas y se salta cualquier id que ya exista. En todo el recorrido, la clave de EveryInfra solo vive en una variable de entorno del servidor: el navegador no puede leerla y el agente de Cursor nunca ve su valor.

Esta separación tiene dos ventajas. La primera es que abrir el tablero no cuesta nada: cinco personas pueden abrirlo veinte veces al día y cada visita solo lee Postgres. La segunda es que el tablero sigue funcionando cuando una fuente falla. Si una fuente no responde en un refresco, el tablero conserva los datos anteriores y enseña la hora de la última actualización correcta.

Dónde vive la clave: secretos de Cursor, NEXT_PUBLIC_ y comprobaciones al publicar

Lovable cuenta en su blog que bloquea unas 1.200 claves privadas al día que los usuarios intentan pegar en el código; en mayo de 2025, Semafor contó 170 sitios de Lovable vulnerables por bases de datos mal configuradas. Cursor pone tres barreras en ese camino.

La primera barrera es el almacén de secretos. La documentación de Apps explica que Cursor pide los secretos que necesita la app y que el agente nunca ve los valores. Lo normal es que un administrador cree secretos de equipo en el panel de Apps; las personas con permiso también pueden crear secretos personales. Para este tablero eso significa un único secreto de equipo llamado EVERYINFRA_API_KEY, y el código solo lee process.env.EVERYINFRA_API_KEY.

Cada agente en la nube trabaja en su propia máquina virtual: la visión general de seguridad de Cloud Agents dice que un agente no ve el código ni el entorno de otro y que el personal de Cursor no accede al código de esas máquinas. Ese entorno de desarrollo tiene otros tipos de secreto. La documentación de Secrets & Network distingue tres. Una Environment Variable es visible para el agente, así que solo sirve para ajustes que no son sensibles. Un Runtime Secret también se carga como variable de entorno, pero Cursor sustituye su valor por [REDACTED] en la salida de herramientas, las transcripciones, los commits y sus mensajes. Un Build Secret solo existe durante la construcción de Docker.

Si quieres que el agente pruebe una llamada real mientras desarrolla, usa un Runtime Secret y no una Environment Variable. La documentación avisa además de que un Runtime Secret sigue siendo visible para quien abra el entorno del agente desde la terminal.

La segunda barrera es el framework. Cursor no impone ninguno y nuestro ejemplo usa Next.js. La guía de variables de entorno de Next.js dice que las variables sin el prefijo NEXT_PUBLIC_ solo existen en el entorno de Node.js, mientras que las que lo llevan se incrustan en el JavaScript que llega al navegador en el momento de construir. Por eso el nombre de la clave no puede empezar por NEXT_PUBLIC_ y la llamada a la API tiene que estar en un Route Handler o en una Server Action. Conviene escribir esta regla en las instrucciones: es más fácil que encontrar el error después.

La tercera barrera es la comprobación al publicar. La sección de seguridad de Apps enumera cuatro controles que corren antes de cada publicación, incluso con la revisión de seguridad desactivada: un archivo con una clave o un token detiene la publicación; también la detienen las claves privadas, las claves de cuentas de servicio y los archivos de tokens; y Cursor no publica archivos .env ni source maps. Por encima va una revisión de seguridad hecha con IA.

Los administradores pueden añadir reglas a esa revisión, pero no quitar los controles de serie. También pueden aprobar una publicación que la revisión ha bloqueado, salvo en tres casos: código malicioso, secretos escritos en el código y credenciales expuestas.

Estas barreras frenan dos errores, la clave en un archivo y la clave dentro del paquete del navegador, pero no un tercero: que otra persona use una clave que tú repartiste. Las claves de EveryInfra se cobran por llamada, así que recomendamos una clave solo para el tablero; si hay que cambiarla, basta con sustituir un valor en el panel de Apps. La chuleta de gestión de secretos de OWASP da como práctica básica separar secretos por servicio y poder rotarlos rápido. Si el repositorio está en GitHub, el escaneo de secretos revisa además todo el historial de Git en busca de credenciales; en repositorios privados hace falta Secret Protection.

Ejemplo de configuración: las instrucciones para el agente

Estas son las instrucciones que escribimos para el agente en la nube, ya adaptadas al equipo de Madrid. No ejecutamos la parte de Cursor, así que esta sección y la siguiente son ejemplos de configuración. Cada parámetro de EveryInfra está contrastado con el catálogo. Las instrucciones tienen que decir «build an app» de forma explícita: según la documentación de Apps, es lo que hace entrar al agente en el flujo de creación de apps.

Build an app: a competitor review board for our personal finance app (Spain).

Data: call EveryInfra from the server only.
- POST https://api.everyinfra.com/api/v1/social
- Header: Authorization: Bearer ${EVERYINFRA_API_KEY}  (team secret; never NEXT_PUBLIC_)
- Sources (one call each per refresh):
  app_store/reviews   {"app_id": "672220319", "country": "es", "sort": "newest", "limit": 30}   # Fintonic
  google_play/reviews {"app_id": "com.fintonic", "language": "es", "sort": "newest", "limit": 40}
  trustpilot/reviews  {"company": "fintonic.com", "sort": "newest", "limit": 20}
  app_store/reviews   {"app_id": "1459319842", "sort": "newest", "limit": 30}   # Monarch (US)
  google_play/reviews {"app_id": "com.monarchmoney.mobile", "sort": "newest", "limit": 40}
  trustpilot/reviews  {"company": "monarchmoney.com", "sort": "newest", "limit": 20}
  reddit/search       {"keyword": "YNAB Monarch", "sort": "newest", "limit": 25}
Storage: Postgres table reviews(source, competitor, review_id, rating, title, text, posted_at, fetched_at),
  unique (source, review_id); upsert with ON CONFLICT DO NOTHING. Do not store author names.
Refresh: POST /api/refresh, allowed only for requests that come with a Cursor API key.
  On HTTP 429 or 503 read error.retry_after, retry once, then keep yesterday's data and
  record last_success_at per source.
Pages: (1) new 1-2 star reviews since last refresh, (2) rating mix per competitor per source,
  (3) Reddit posts list. UI language: Spanish. Share with: our team only.

Cada línea responde a algo de las secciones anteriores. El nombre del secreto y la advertencia sobre NEXT_PUBLIC_ salen de la guía de Next.js. La restricción unique (source, review_id) existe porque la misma reseña vuelve en muchos refrescos. El tratamiento de 429 y 503 cubre los dos errores que la API marca como reintentables. Los valores de limit salen de las mediciones de cobertura que damos más abajo. La orden de no guardar nombres de autor responde a que el seudónimo pertenece a una persona particular y el tablero no lo necesita.

Ejemplo de configuración: la ruta de refresco y la tabla

Lo que escribe el agente cambia en cada ejecución. Este es el mínimo que esperamos en la ruta de refresco, para que puedas compararlo con lo que genere. Es un Route Handler de Next.js y solo corre en el servidor.

// app/api/refresh/route.ts — ejemplo de configuración, solo servidor
import { sql } from "@/lib/db";

const SOURCES = [
  { source: "app_store", competitor: "fintonic", body: { platform: "app_store", action: "reviews", params: { app_id: "672220319", country: "es", sort: "newest", limit: 30 } } },
  { source: "google_play", competitor: "fintonic", body: { platform: "google_play", action: "reviews", params: { app_id: "com.fintonic", language: "es", sort: "newest", limit: 40 } } },
  { source: "reddit", competitor: "us_market", body: { platform: "reddit", action: "search", params: { keyword: "YNAB Monarch", sort: "newest", limit: 25 } } },
];

async function callOnce(body: object) {
  const res = await fetch("https://api.everyinfra.com/api/v1/social", {
    method: "POST",
    headers: { Authorization: `Bearer ${process.env.EVERYINFRA_API_KEY}`, "Content-Type": "application/json" },
    body: JSON.stringify(body),
  });
  return { status: res.status, json: await res.json() };
}

export async function POST() {
  const report = [];
  for (const s of SOURCES) {
    let r = await callOnce(s.body);
    if (r.status === 429 || r.status === 503) {
      const wait = Math.min((r.json?.error?.retry_after ?? 30) * 1000, 120_000);
      await new Promise((ok) => setTimeout(ok, wait));
      r = await callOnce(s.body);
    }
    if (r.status !== 200) { report.push({ ...s, ok: false, status: r.status }); continue; }
    for (const row of r.json.results ?? []) {
      await sql`INSERT INTO reviews (source, competitor, review_id, rating, title, text, posted_at, fetched_at)
                VALUES (${s.source}, ${s.competitor}, ${row.id}, ${row.rating ?? row.score ?? null},
                        ${row.title ?? null}, ${row.text ?? null}, ${row.posted_at}, now())
                ON CONFLICT (source, review_id) DO NOTHING`;
    }
    await sql`UPDATE sources SET last_success_at = now() WHERE source = ${s.source} AND competitor = ${s.competitor}`;
    report.push({ ...s, ok: true, rows: r.json.results?.length ?? 0, charged_usd: r.json.billing?.charged_usd });
  }
  return Response.json(report);
}

Para evitar duplicados se usa INSERT … ON CONFLICT DO NOTHING de Postgres. La documentación de PostgreSQL explica que ON CONFLICT permite indicar una acción alternativa en lugar de lanzar el error de restricción única. Así, cuando la misma reseña vuelve al día siguiente, la tabla sigue teniendo una sola fila. La columna fetched_at guarda el momento de la primera descarga, y el tablero marca como «nuevas» las reseñas según fetched_at, no según posted_at; la sección de pruebas explica por qué.

Los nombres de campo cambian según el sitio. App Store y Trustpilot llaman rating a las estrellas; Google Play las llama score. Los mensajes de Reddit no tienen estrellas, solo like_count y comment_count. Todo se puede comprobar en response_fields del catálogo, sin adivinar.

Una petición real: llamada, respuesta y cobro

Esta es una petición real que enviamos el 13 de noviembre de 2026 a las 21:54:52, hora de Singapur (14:54:52 en Madrid). Pide las 30 reseñas más recientes de Fintonic en la App Store española. La clave entra por una variable de entorno, así que el comando solo muestra su nombre.

curl -s https://api.everyinfra.com/api/v1/social \
  -H "Authorization: Bearer $EVERYINFRA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"platform":"app_store","action":"reviews","params":{"app_id":"672220319","country":"es","sort":"newest","limit":30}}'

La respuesta llegó en 0,74 segundos con HTTP 200 y count 30. El campo billing.charged_usd valía 0,001389, igual que el precio del catálogo, y el JSON completo ocupaba unos 16,2 KB. Cada reseña traía los mismos campos que lista response_fields en el catálogo: id, title, text, rating, rating_scale, author, app_version, helpful_count, posted_at, app_id, app_name y platform. Los textos llegan en español tal como los escribieron los usuarios, sin traducir.

El tablero usa solo 7 de esos campos. El campo author es el seudónimo de una persona particular, así que lo descartamos antes de guardar la fila; por eso no aparece ningún nombre de autor en las capturas ni en las tablas de este artículo. La captura de abajo corresponde a la llamada equivalente para YNAB en la App Store de Estados Unidos, hecha 23 minutos antes con la misma forma de respuesta.

Prueba real: tres momentos, cuatro capacidades y lo que devolvió cada una

El lado del tablero es un ejemplo de configuración, pero el lado de los datos lo llamamos de verdad. La noche del 13 de noviembre de 2026 lanzamos el mismo grupo de llamadas que hace un refresco del tablero en tres momentos: 21:31, 22:14 y 22:36, hora de Singapur (14:31, 15:14 y 15:36 en Madrid). El tablero hace 7 llamadas: Fintonic y Monarch en las tres tiendas, más Reddit. En la prueba, la App Store de Fintonic entró desde la primera ronda y su Google Play y su Trustpilot desde la segunda; además, cada ronda llamó a YNAB en las tres tiendas como segunda referencia. En cada petición anotamos el estado HTTP, el tiempo de respuesta, el número de filas y billing.charged_usd. Guardamos todas las respuestas originales, así que cada cifra de esta sección se puede recalcular. La tabla recoge App Store y Reddit en las tres rondas; Google Play y Trustpilot están en la sección de la tercera ronda.

Las reseñas más recientes de App Store no cambiaron en las tres rondas. En YNAB, Monarch y Fintonic, las 30 reseñas de las rondas posteriores fueron idénticas a las de la primera, con los mismos id y en el mismo orden: 0 nuevas. La antigüedad de la reseña más nueva crecía al ritmo del reloj, de 57,6 a 58,7 horas en YNAB y de 66,5 a 67,2 horas en Fintonic. Es decir, en ese tiempo la tienda no publicó ninguna reseña nueva.

En Reddit tampoco apareció nada nuevo. Las dos primeras rondas devolvieron los mismos 9 mensajes y solo se movieron los votos: el debate del 9 de noviembre pasó de 280 a 283, y en la tercera ronda tenía 284. Los 23 mensajes de la tercera ronda se publicaron todos antes de la primera. El mismo mensaje vuelve en varios refrescos, así que el tablero debe quitar duplicados por la URL del mensaje y decidir qué es nuevo según posted_at, no según «lo he descargado por primera vez».

Las reseñas tardan uno o dos días en hacerse públicas, así que con un refresco por hora 23 de cada 24 llamadas traen las mismas reseñas y la API cuesta 24 veces más. Con uno al día basta; si se quiere algo más ágil, como mucho cada 6 horas.

Las fuentes van a velocidades muy distintas. Cada llamada con éxito a App Store tardó entre 0,42 y 0,74 segundos; a Google Play, entre 7,0 y 9,3; la búsqueda «YNAB Monarch» en Reddit, 8,86 y 10,54; y a Trustpilot, entre 26,37 y 53,35. En la tercera ronda, las 7 llamadas del tablero suman unos 107 segundos, 80 de ellos en las dos de Trustpilot (53,35 la de Fintonic). Conviene dar a cada llamada un tiempo de espera holgado, a Trustpilot al menos un minuto, o lanzar las fuentes en paralelo para que el total lo marque la más lenta.

503 y 429: cómo debe reaccionar el tablero

En las dos primeras rondas, Google Play y Trustpilot devolvieron 503; no se cobró nada y el reintento de la tercera ronda funcionó, a precio de catálogo. Un ejemplo de esas respuestas (22:14:53, hora de Singapur, google_play/reviews, YNAB): error.code era unavailable, error.retryable era true, billing.charged era false, charged_usd era 0 y refund.status indicaba succeeded.

Los dos errores significan cosas distintas en HTTP, así que el tablero debe tratarlos de forma distinta. La RFC 6585 define el 429 como «demasiadas peticiones»: enviaste muy rápido y basta con esperar un poco. La RFC 9110 define el 503 como un problema temporal del servidor, que puede indicar con Retry-After cuándo volver.

La ruta de refresco, por tanto, hace lo siguiente. Ante un 429, espera lo que marca retry_after y lo intenta una vez más. Ante un 503, también reintenta una sola vez. Si vuelve a fallar, salta esa fuente, conserva los datos de ayer y muestra en esa columna la hora de la última actualización correcta. Para eso está el campo last_success_at del ejemplo de configuración.

Lo que no conviene es reintentar en bucle hasta que funcione: si la ruta se queda esperando a una fuente, las demás no llegan a escribir sus filas. Con un estado separado por fuente, una fuente sin actualizar solo afecta a su columna y las otras se actualizan con normalidad. Por eso la ruta hace llamadas separadas: con una sola petición por lotes, un fallo podría bloquearlas todas. En la interfaz, cada columna enseña la hora de su último refresco correcto.

Cuántos días cubren 30 reseñas: primero medir el ritmo, después fijar el parámetro `limit`

El valor de limit depende de cuántas reseñas recibe cada competidor al día. Lo medimos con las respuestas de la primera ronda. Las 30 reseñas más recientes de Fintonic en la App Store española van del 1 de octubre al 10 de noviembre de 2026: 40,4 días, unas 0,74 reseñas al día. En Estados Unidos, las 30 últimas de YNAB cubren 29,1 días (1,03 al día) y las de Monarch solo 8,6 días (3,48 al día).

Para el equipo de Madrid esto se traduce en parámetros concretos. Con un refresco diario, Fintonic suma menos de una reseña nueva al día en la App Store española, así que limit: 30 deja margen para más de un mes; aunque el refresco falle una semana entera, una sola descarga lo recupera todo. No subimos limit hasta el máximo de 500: el cobro es por llamada y no cambiaría, pero cada respuesta pasaría de unos 16 KB a varios cientos y la escritura en la base de datos y la eliminación de duplicados irían más lentas. Solo merece la pena un limit alto la primera vez, para cargar el histórico.

Hay otra cifra que el tablero debe enseñar: cuánto tiempo ha pasado desde la reseña más nueva en el momento de la petición. En la llamada de las 21:54 (hora de Singapur), la reseña más reciente de Fintonic se había publicado el 10 de noviembre a las 12:24, hora del Pacífico de EE. UU., es decir, 66,5 horas antes. En YNAB y Monarch la distancia era de 57,6 y 56,7 horas. La ayuda de Google Play Console indica que las reseñas nuevas suelen retenerse unas 24 horas, y en las tres muestras de App Store la primera reseña tenía más de dos días. Por eso «nuevas hoy» en el tablero quiere decir «vistas por primera vez hoy», nunca «escritas hoy».

Estrellas y temas de las reseñas bajas: dónde pierde puntos Fintonic

El reparto de estrellas de Fintonic en la App Store española es muy distinto al de las apps de Estados Unidos. De las 30 reseñas más recientes, 15 son de 1 estrella y 6 de 2 estrellas: el 70 % son reseñas bajas, frente al 33,3 % de YNAB y el 36,7 % de Monarch. Solo 4 son de 5 estrellas. La muestra es pequeña y una reseña equivale a 3,3 puntos, así que el tablero debe mostrar el número de reseñas y no solo el porcentaje.

La tabla recoge los temas de las 21 reseñas bajas de Fintonic. Como referencia de precio, YNAB cobra 109 USD al año o 14,99 USD al mes según su página de precios, y la de Monarch asegura que nunca vende los datos financieros de sus usuarios. Una sola persona, quien firma el artículo, leyó una a una las 21 reseñas de 1 y 2 estrellas de Fintonic y asignó un solo tema a cada una, según la primera queja del texto; nadie más revisó las etiquetas, así que las cifras describen esta muestra y nada más. Las etiquetas están en los datos originales; con el tablero en marcha, ese trabajo lo puede hacer una regla sencilla o un modelo.

Las versiones apuntan en la misma dirección. Las 30 reseñas cubren de la 10.0.5 a la 10.0.10. Las 7 escritas con la 10.0.7 son todas de 1 o 2 estrellas (3 hablan de venta de productos y 2 del rediseño); con la 10.0.10, la más reciente, son bajas 6 de 12. En esta muestra, varias reseñas piden una herramienta que solo controle gastos, sin venta de productos y con una conexión bancaria fiable. Conviene recordar que son opiniones de usuarios. Una reseña enseña un problema percibido, no demuestra qué hace o deja de hacer la empresa, y el tablero debe guardar esa misma distancia.

La tabla siguiente pone a Fintonic al lado de las dos apps estadounidenses con las mismas medidas. Sirve para calibrar el tablero: una app con 0,74 reseñas al día y un 70 % de reseñas bajas necesita alertas distintas que una con 3,48 reseñas al día y un 36,7 %.

En Estados Unidos los temas son otros, con muestras aún más pequeñas y la misma regla de etiquetado. Entre las 10 reseñas bajas de YNAB, 4 hablan del precio y 3 de la interfaz; entre las 11 de Monarch, 3 de privacidad, 2 de sincronización, 2 de exactitud, 1 del iPhone Duo y 1 de la actualización obligatoria. Dos reseñas de Monarch (una de 1 estrella y otra de 4) y una de YNAB (de 1 estrella) piden soporte para el iPhone Duo, que se empezó a entregar el 23 de octubre. Una reseña de 5 estrellas de Monarch dice que el conector MCP es «claramente un elemento diferenciador»; es la única mención a IA en las 90 reseñas de las tres apps.

Las dos fuentes de la tercera ronda: un mismo competidor, tres sitios, tres reputaciones

En la tercera ronda, a las 22:37 hora de Singapur, los reintentos a Google Play y Trustpilot funcionaron y por fin tuvimos las reseñas más recientes de cada competidor en los tres sitios. Los datos de App Store son de la primera ronda (las tres fueron idénticas); los de Google Play y Trustpilot, de la tercera.

Primero, en esta muestra la cuota de reseñas bajas de Fintonic es aún mayor en Google Play: 34 de las 40 reseñas recientes en español son de 1 o 2 estrellas, un 85 %, frente al 70 % de la App Store española. Lo mismo pasa con YNAB y Monarch en Estados Unidos, aunque con menos diferencia: su cuota baja en Google Play supera la de App Store en 8 a 10 puntos (43 % frente a 33 % en YNAB y 45 % frente a 37 % en Monarch). Y Fintonic contestó a las 40 reseñas de Google Play, todas. Para un equipo pequeño que quiera competir con Fintonic, ese ritmo de respuesta marca el listón: se calcula fácil mirando si reply_text viene vacío.

Segundo, en Trustpilot las estrellas dependen mucho de quién pidió la reseña. YNAB tiene 1 reseña baja de 20 y 15 de cinco estrellas; Monarch, 18 bajas de 20 y una sola de cinco. En YNAB, 18 de las 20 reseñas llevan source: InvitationApi y verification_level: verified, es decir, la empresa invitó a esos usuarios a opinar mediante la API de invitaciones de Trustpilot, y las 18 tienen tres estrellas o más. Las 20 de Monarch son espontáneas (source: Organic); la más reciente es del 21 de septiembre de 2026 y entre todas abarcan 323 días. La documentación para desarrolladores de Trustpilot incluye una API para empresas que envía invitaciones. En estas dos muestras de 20 reseñas, la empresa que invita tiene más reseñas de cinco estrellas y la que no invita, más reseñas bajas; con dos empresas no se puede hablar de causa, pero sí queda claro que las estrellas de Trustpilot no se comparan sin mirar source.

Fintonic está en un punto intermedio y con muy poco volumen: solo 8 reseñas en 501 días, 5 de ellas por invitación (verification_level: invited), y respondió a las 8. En la práctica, los usuarios españoles hablan de Fintonic en las dos tiendas de apps, no en Trustpilot.

Por eso la columna de Trustpilot del tablero necesita dos filas según source: las reseñas por invitación y las espontáneas. Para comparar competidores con justicia, hay que mirar solo las espontáneas; con 2 en el caso de YNAB, la muestra es demasiado pequeña para sacar conclusiones.

Reddit: hacia dónde se mueven los usuarios en Estados Unidos

En la misma ronda buscamos «YNAB Monarch» con reddit/search, ordenado por fecha, y obtuvimos 9 mensajes del 25 de octubre al 10 de noviembre, con 515 comentarios en total. Tres son mensajes de cambio de app; la tabla los recoge con las cifras de la primera ronda.

Cinco son anuncios de productos nuevos, y uno de ellos compara directamente la función de finanzas personales de Claude con Monarch.

El mensaje con más actividad no habla de cambiar de app. Es un debate en r/MonarchMoney del 9 de noviembre sobre la actitud de los usuarios ante las funciones de IA en presupuestos, con 280 votos y 179 comentarios, publicado cuatro días después del lanzamiento de Personal Finance en Claude. Para el equipo de Madrid, esta columna sirve para ver qué funciones nuevas comentan los usuarios de las apps estadounidenses, antes de decidir si copiarlas.

¿Y Fintonic en Reddit? En las rondas 2 y 3 añadimos una búsqueda de «Fintonic», ordenada por fecha, para comprobarlo. Las dos rondas devolvieron los mismos 2 mensajes del último mes, y ninguno es de un foro español:

Para el mercado español, por tanto, esa columna aporta poco. Cada búsqueda costó 0,000792 USD; si un día no hay coincidencias, la llamada cuenta como resultado vacío y no se cobra, así que mantenerla tampoco sale caro.

Cuánto cuesta la API con un refresco al día

El cálculo usa el price_usd del catálogo y lo contrastamos con los cobros reales: todas las llamadas con éxito cobraron exactamente el precio del catálogo y todas las fallidas cobraron 0. En la tercera ronda, las 7 llamadas del tablero funcionaron y el cobro real fue exactamente 0,009126 USD. Si el tablero sigue a dos competidores en las tres tiendas y añade una búsqueda en Reddit, cada refresco hace siete llamadas.

Un refresco al día cuesta 0,009126 USD, menos de un céntimo de dólar. En 30 días son unos 0,27 USD y en un año unos 3,33 USD. Con un refresco cada hora, el mes sale por 6,57 USD, 24 veces más, y la sección de rondas muestra que esas 23 llamadas extra casi nunca traen reseñas nuevas. Las llamadas fallidas o sin resultados no se cobran.

En el lado de Cursor, un asiento Premium cuesta 30 USD al mes, más el uso del agente en la nube mientras construye, que no medimos. Una vez publicado el tablero, la API cuesta unos 0,27 USD al mes, alrededor del 0,9 % de la cuota de Premium.

Cómo lanzar el refresco diario y cuánto cuesta cada opción

La documentación de Apps no menciona un programador de tareas propio, así que el refresco diario necesita un disparador externo. Comparamos tres opciones, todas basadas en funciones que la documentación describe.

La primera es refrescar al abrir. Cuando se carga la página, el servidor mira last_success_at de cada fuente; si una fuente tiene más de 24 horas, lanza un refresco, y el resto de visitas solo leen Postgres. No hay nada que configurar. El precio es que un día sin visitas no trae datos nuevos y que la primera persona del día siguiente espera a que terminen las llamadas (en la tercera ronda, las 7 llamadas del tablero suman unos 107 segundos y cada una de Trustpilot pasó de 26; conviene enseñar primero los datos anteriores y cambiarlos cuando acabe el refresco en segundo plano). Para un equipo pequeño que abre el tablero cada mañana, basta.

La segunda es un programador externo con una API key de Cursor. La documentación de Apps explica que las apps privadas y de equipo están detrás del inicio de sesión de Cursor, que las herramientas automáticas no pueden superar. Una API key de Cursor enviada en la cabecera x-cursor-app-token permite que una herramienta use la app como si fuera una persona con sesión iniciada. La clave solo funciona en la cabecera, no como parámetro de la URL ni como cookie, y Cursor marca estas peticiones como automáticas. Una API key de equipo solo abre las apps de equipo que se le asignen.

Nosotros pusimos el programador en el disparador schedule de GitHub Actions, que envía un POST /api/refresh cada mañana.

# .github/workflows/refresh-board.yml — config example
on:
  schedule:
    - cron: "0 7 * * *"   # 07:00 UTC = 08:00 en Madrid (horario de invierno)
  workflow_dispatch: {}
jobs:
  refresh:
    runs-on: ubuntu-latest
    steps:
      - run: |
          curl -sf -X POST "https://<your-app-domain>/api/refresh" \
            -H "x-cursor-app-token: ${{ secrets.CURSOR_APP_TOKEN }}"

Este montaje reparte dos claves en dos sitios. Los secretos de GitHub guardan solo la API key de Cursor, que abre esta única app. La clave de EveryInfra se queda en el almacén de secretos de Apps y GitHub nunca la ve. Ten en cuenta que cron en GitHub Actions va en UTC: cuando España cambie al horario de verano, el refresco llegará una hora más tarde en Madrid, salvo que ajustes la expresión.

La tercera opción son las Automations de Cursor. La documentación de Automations explica que un disparador programado lanza un agente en la nube en segundo plano, a partir de un valor predefinido o de una expresión cron. Una ejecución «puede retrasarse, pero no empezará antes de la hora indicada», y se factura como uso de agentes en la nube. Es decir, un agente diario que solo llame a la ruta de refresco cuesta una ejecución de modelo al día, cuando el refresco en sí no necesita ninguna decisión de un modelo.

Un hilo del foro de Cursor de septiembre de 2026 añade que las ejecuciones programadas solo dejan su resultado en el historial, salvo que se añada una herramienta de entrega como el envío a Slack. Nuestra conclusión es sencilla: para refrescar, la opción uno o la dos. Las Automations encajan mejor en un resumen semanal que un agente escribe a partir del tablero, porque ese paso sí necesita un modelo.

Límites y cosas que comprobar

Empecemos por Cursor. Build Live Apps necesita un agente en la nube, y Free y Plus no lo tienen. En Teams y Enterprise, los administradores pueden desactivar Apps para todo el equipo y también impedir que las API keys abran apps, lo que elimina la segunda opción de refresco. Los repositorios tienen que estar en Cursor Origin o GitHub; GitLab figura como «coming soon».

La sección de disponibilidad de Apps dice que el alojamiento está separado de los servicios de Cursor y se ofrece «tal cual». Cursor puede retirar un subdominio o una app por incumplir los términos o por motivos de negocio. Si el tablero importa, guarda también el código en tu propio repositorio.

Ahora, los datos. Las cuatro capacidades leen solo contenido público: reseñas públicas de las tiendas, reseñas públicas de Trustpilot y mensajes públicos de Reddit. Las API oficiales de Apple y Google solo enseñan a cada desarrollador las reseñas de sus propias apps. El recurso Customer Reviews de App Store Connect obtiene «the customer reviews for your app». La API Reply to Reviews de Google Play cubre las versiones de producción de tu propia app, devuelve solo reseñas con texto y tiene una cuota de 200 peticiones GET por hora. Ninguna de las dos te deja ver las reseñas de Fintonic si no eres Fintonic. Con las otras dos fuentes pasa algo parecido: la documentación para desarrolladores de Trustpilot ofrece a las empresas API para enviar invitaciones, mostrar sus reseñas y responderlas, y el acceso a toda la base de reseñas es una oferta aparte, Data Solutions. Si quieres usar tú la API oficial de Reddit, lee antes sus Data API Terms, revisadas por última vez el 20 de julio de 2026.

Las reseñas además llegan con retraso. La ayuda de Google Play Console indica que las valoraciones y reseñas nuevas suelen retenerse unas 24 horas y que, si Google detecta actividad sospechosa, puede pausar todas las reseñas públicas nuevas de una app. La página de valoraciones y reseñas de Apple explica que un desarrollador puede reiniciar la nota resumida con una versión nueva, pero las reseñas escritas se mantienen. Por eso «nuevas hoy» significa «descargadas hoy» y la interfaz tiene que decirlo.

Por último, las personas. El seudónimo de quien escribe una reseña pertenece a un particular y el tablero no lo necesita, así que se descarta antes de guardar la fila; si se cita una reseña, se cita el texto sin el nombre. Para un equipo en la Unión Europea, no guardar datos personales que no hacen falta es además la forma más sencilla de cumplir el principio de minimización del RGPD. Una reseña puede señalar un problema de producto, pero no prueba que un competidor haya incumplido una ley o haya mentido. Las notas del tablero deberían mantener esa distancia.

Novedades del sector: octubre y noviembre de 2026

• 5 de noviembre de 2026: Cursor lanza Build Live Apps. (changelog, 2026-11-05) Para ti: una herramienta interna se ahorra tres pasos entre «funciona en mi portátil» y «el equipo puede abrirla»: alojamiento, base de datos e inicio de sesión. En un tablero que trae datos de fuera, la gestión de la clave es lo único que sigue en tus manos.
• 5 de noviembre de 2026: Anthropic lanza Personal Finance en Claude, en beta. (Anthropic, centro de ayuda, TechCrunch, 2026-11-05) Para ti: de momento es solo para Estados Unidos, pero las apps de finanzas ya compiten también con un asistente general. Añade al tablero una vista de «con quién nos comparan».
• 4 de noviembre de 2026: Apple abre los mensajes de retención para suscripciones. (Apple Developer News, 2026-11-04) Para ti: las apps de suscripción tienen una oportunidad más de hablar cuando alguien cancela, y las quejas sobre renovaciones de la competencia son material directo para ese mensaje.
• 23 de octubre de 2026: el iPhone Duo llega a los compradores. (Apple Newsroom, 2026-10-23) Para ti: en nuestra muestra, YNAB y Monarch tienen una reseña de 1 estrella cada una por no adaptarse aún al iPhone Duo.
• 21 de octubre de 2026: Monarch reabre su conector MCP. (blog de Monarch, centro de ayuda, 2026-10-21) Para ti: un competidor ya vende «funciona con tus herramientas de IA» como ventaja, y una reseña de 5 estrellas de nuestra muestra lo llama elemento diferenciador.
• 20 y 13 de octubre de 2026: Cursor publica el Agent SDK y abre el Origin App Marketplace. (Agent SDK, Origin App Marketplace, 2026-10-20 y 2026-10-13) Para ti: los canales del Agent SDK pueden despertar a un agente con un horario cron, útil para un resumen semanal, y el marketplace de Origin incluye apps de despliegue como Vercel y Cloudflare, por si más adelante quieres sacar el tablero del alojamiento de Cursor.

Primeros pasos

Regístrate en EveryInfra, crea una clave solo para el tablero y haz una llamada de prueba en las páginas de reseñas de App Store y búsqueda en Reddit para revisar parámetros y campos; precios y uso, en la página de precios. Si prefieres probar antes en el editor, instala el servidor MCP remoto de EveryInfra en Cursor (página de configuración MCP, Datos de TikTok, Instagram y Amazon en Cursor: prueba del plugin): en el chat descubres qué capacidades y parámetros necesitas y luego copias esas llamadas a la ruta de refresco. Si lo que buscas es un agente que lea cada día las reseñas bajas de tu propia app y abra incidencias, mira Automatizaciones en la nube de VS Code Copilot: clasificar a diario las reseñas de tu app.

Preguntas frecuentes

Cursor build live app builder: ¿es un creador de apps como los demás y qué tipo de app puede hacer?

(Pregunta a partir de la sugerencia de búsqueda «cursor build live apps app builder», leída el 13 de noviembre de 2026.) Sí, en el sentido de que describes una app y Cursor la construye, la aloja y te da un enlace. La documentación de Apps habla de aplicaciones web con base de datos Postgres opcional e inicio de sesión de Cursor; no menciona apps nativas para móvil. Como las apps quedan por defecto detrás del inicio de sesión de Cursor, encajan sobre todo con herramientas internas, que es justo el caso de un tablero de reseñas para el equipo.

Cursor build live apps not working: ¿por qué no encuentro la opción de crear la app?

(Sugerencia «cursor build live apps not working».) Revisa cuatro cosas. Primero, que uses un agente en la nube: la documentación de Apps dice que los agentes locales no están soportados. Segundo, el plan: según la documentación de Cloud Agents, Free y Plus no incluyen agentes en la nube. Tercero, que un administrador no haya desactivado Apps para el equipo. Cuarto, que las instrucciones digan «build an app». Además, Cursor solo inyecta los secretos nuevos al arrancar un agente, así que después de crear uno hay que lanzar un agente nuevo.

Cursor build live apps React: ¿qué framework usa la app?

(Sugerencia «cursor build live apps react».) La documentación no fija ninguno: solo dice que Cursor monta la app web, añade Postgres si hace falta y configura el inicio de sesión y el alojamiento. Puedes pedir un framework en las instrucciones. Nuestro ejemplo usa Next.js, que es React, porque sus rutas de servidor y la regla de NEXT_PUBLIC_ dejan claro cómo mantener la clave en el servidor. El framework no cambia la forma de llamar a EveryInfra: siempre es un POST HTTPS desde el servidor.

Cursor live apps para Mac o Windows: ¿hay que instalar algo?

(Sugerencias «cursor live apps for mac» y «cursor live apps windows».) No. El agente en la nube construye y despliega la app en la nube de Cursor; tu ordenador solo lanza el encargo. La documentación de Cloud Agents enumera siete formas de lanzarlo: la app de iOS, la web, la app de escritorio, Slack, comentarios en GitHub o Bitbucket, Linear y la API. Sirve el escritorio en Mac, Windows o Linux, y también el móvil.

Cursor live apps free: ¿funciona con el plan gratuito?

(Sugerencia «cursor live apps free».) No. La página de precios de Cursor, leída el 13 de noviembre, y la documentación de Cloud Agents muestran que Free y Plus no tienen agentes en la nube; Premium, a 30 USD al mes, es el primer nivel que los incluye. La documentación no menciona una tarifa aparte por el alojamiento después de publicar. EveryInfra cobra por llamada y sin cuota mensual; la sección de costes calcula el gasto diario del tablero.

Competitor review monitoring free: ¿hay una forma gratuita de vigilar las reseñas de la competencia?

(Sugerencia «competitor review monitoring free».) La única totalmente gratuita es abrir cada día a mano la ficha de cada competidor en las tiendas. Las API oficiales de Apple y Google solo devuelven las reseñas de tus propias apps, como explica la sección de límites. El método de este artículo costó en nuestra prueba menos de un céntimo de dólar al día en llamadas, más un asiento Premium de Cursor. Si ya tienes un servidor, puedes poner la misma ruta de refresco en tu propio programador y prescindir de Cursor.

¿Es esto el nuevo v0? ¿En qué se diferencia de Lovable o Replit?

(Pregunta del hilo de Reddit r/cursor «Cursor can now build + deploy internal apps».) La idea es parecida: describes una app y la herramienta la construye y la aloja. The New Stack la comparó con Lovable y Replit y concluyó que Cursor apunta más a herramientas internas de empresa. Para un tablero de reseñas importan dos diferencias. Las apps de Cursor quedan detrás del inicio de sesión de Cursor por defecto, lo que encaja con una página solo para el equipo. Y la comprobación de secretos al publicar es obligatoria: ni un administrador puede aprobar una clave escrita en el código.

Referencias

1. Build live apps, Cursor changelog, 2026-11-05, https://cursor.com/changelog/build-live-apps
2. Apps, Cursor Docs, https://cursor.com/docs/cloud-agent/apps
3. Cloud Agents, Cursor Docs, https://cursor.com/docs/cloud-agent
4. Cloud Agents security, Cursor Docs, https://cursor.com/docs/cloud-agent/security
5. Secrets & Network, Cursor Docs, https://cursor.com/docs/cloud-agent/security-network
6. Automations, Cursor Docs, https://cursor.com/docs/cloud-agent/automations
7. Pricing, Cursor, https://cursor.com/pricing
8. Start from scratch, Cursor changelog, 2026-08-27, https://cursor.com/changelog/start-from-scratch
9. Agent SDK, Cursor changelog, 2026-10-20, https://cursor.com/changelog/agent-sdk
10. Origin App Marketplace, Cursor changelog, 2026-10-13, https://cursor.com/changelog/origin-app-marketplace
11. Model Context Protocol (MCP), Cursor Docs, https://cursor.com/docs/mcp
12. Most apps never make it off localhost: Cursor takes on Lovable and Replit with fully managed app deployment, The New Stack, 2026-11-05, https://thenewstack.io/cursor-ai-app-deployment/
13. Vercel for Platforms, Vercel, https://vercel.com/for/platforms
14. Cursor can now build + deploy internal apps, Reddit r/cursor, 2026-11, https://www.reddit.com/r/cursor/comments/1xoxyh5/cursor_can_now_build_deploy_internal_apps_hosting/
15. Cron/MCP-only automations: repo warning, no output surface, Cursor Forum, 2026-09, https://forum.cursor.com/t/cron-mcp-only-automations-repo-warning-no-output-surface-broken-add-flow/172146
16. Customer Reviews, Apple Developer Documentation, App Store Connect API, https://developer.apple.com/documentation/appstoreconnectapi/customer-reviews
17. Ratings, reviews, and responses, Apple Developer, https://developer.apple.com/app-store/ratings-and-reviews/
18. Retention messages now available, Apple Developer News, 2026-11-04, https://developer.apple.com/news/?id=fk9ps3gv
19. New age rating content descriptors, Apple Developer News, 2026-11-02, https://developer.apple.com/news/?id=yxkh08us
20. Developers bring incredible new app experiences to iPhone Duo, Apple Newsroom, 2026-10-23, https://www.apple.com/newsroom/2026/10/developers-bring-incredible-new-app-experiences-to-iphone-duo/
21. Reply to Reviews API, Google for Developers, https://developers.google.com/android-publisher/reply-to-reviews
22. View and analyze your app's ratings and reviews, Google Play Console Help, https://support.google.com/googleplay/android-developer/answer/138230
23. Trustpilot API documentation, Trustpilot Developers, https://developers.trustpilot.com/
24. Data API Terms, Reddit, Inc., 2026-07-20, https://redditinc.com/policies/data-api-terms
25. Environment variables, Next.js Docs, https://nextjs.org/docs/app/guides/environment-variables
26. Events that trigger workflows: schedule, GitHub Docs, https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule
27. About secret scanning, GitHub Docs, https://docs.github.com/en/code-security/secret-scanning/introduction/about-secret-scanning
28. INSERT, PostgreSQL Documentation, https://www.postgresql.org/docs/current/sql-insert.html
29. RFC 9110: HTTP Semantics, IETF, 2022-06, https://www.rfc-editor.org/rfc/rfc9110
30. RFC 6585: Additional HTTP Status Codes, IETF, 2012-04, https://www.rfc-editor.org/rfc/rfc6585
31. Secrets Management Cheat Sheet, OWASP, https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html
32. The hottest new vibe coding startup Lovable is a sitting duck for hackers, Semafor, 2025-05-29, https://www.semafor.com/article/05/29/2025/the-hottest-new-vibe-coding-startup-lovable-is-a-sitting-duck-for-hackers
33. Lovable: Secure Vibe Coding, Lovable blog, https://lovable.dev/blog/secure-vibe-coding
34. Introducing Personal Finance in Claude, Anthropic, 2026-11-05, https://claude.com/resources/articles/introducing-personal-finance-in-claude
35. Use Personal Finance in Claude, Claude Help Center, 2026-11, https://support.claude.com/en/articles/18185620-use-personal-finance-in-claude
36. Claude can now analyze your spending with its new personal finance tool, TechCrunch, 2026-11-05, https://techcrunch.com/2026/11/05/claude-can-now-analyze-your-spending-with-its-new-personal-finance-tool/
37. Monarch MCP, Monarch blog, 2026-10-21, https://www.monarch.com/blog/monarch-mcp
38. Monarch MCP Connector, Monarch Help Center, https://help.monarch.com/hc/en-us/articles/50207234679956-Monarch-MCP-Connector
39. Pricing, Monarch, https://www.monarch.com/pricing
40. Pricing, YNAB, https://www.ynab.com/pricing