Crea y despliega una tienda de ebooks con Cursor: multiagentes, skills, browser MCP y testing en producción con TestSprite

Cursor se ha convertido en una de las herramientas más completas para crear proyectos, tanto si eres vibecoder como si eres programador y quieres lanzar múltiples agentes con una suscripción barata. En este artículo vamos a construir una aplicación completa desde cero: una tienda de ebooks con backend y frontend separados, pagos con Stripe, correos con Resend, imágenes en Cloudinary, despliegue en Railway y testing automatizado en producción con TestSprite.

Lo interesante del flujo es que Cursor va a hacer casi todo el trabajo: escribe el código, lo prueba él mismo con su browser integrado, mejora la interfaz usando skills, se despliega solo usando CLIs y, ya en producción, se revisa de forma automática.

El plan inicial

Lo primero es crear una carpeta para el proyecto (por ejemplo ebook-shop) y abrirla en Cursor, ya sea arrastrándola o con Open Folder.

Antes de escribir código, activamos el modo Plan de Cursor y redactamos lo que queremos. Este es el prompt exacto que usé:

crea una aplicacion web conformada por un backend y un frontend para venta
de libros, hay un landing page para usuarios, y un panel de control con
multiples roles (admin, vendedor, comprador/cliente) y el stack es: express,
postgresql con prisma, frontend nextjs, integración de pagos con stripe,
envio de correos con resend y alojamiento de imagenes con cloudinary

Un detalle importante: Stripe, Resend y Cloudinary permiten cuentas de prueba gratuitas, así que puedes seguir todo el proceso sin pagar nada.

Cursor responde con algunas preguntas antes de planificar. En este caso:

• ¿Qué tipo de libros vende la tienda? Ebooks digitales, para no complicarnos con direcciones de envío. Luego puedes extenderlo.
• ¿Cómo prefieres la autenticación? Que Next.js consuma el API del backend.

¿Por qué un API separado?

Podrías hacer todo en Next.js, es cierto que permite crear APIs. Pero no es un framework backend y se nota cuando quieres crear algo más complejo. Además, separar el backend te deja la puerta abierta para consumir ese mismo API desde una app móvil u otra aplicación en el futuro. Y como en Cursor puedes tener todo en el mismo proyecto (monorepo), no pierdes comodidad.

El plan generado

Cuando Cursor termina la planificación, muestra un resumen con gráficos navegables de la arquitectura: el frontend Next.js comunicándose con Express, las rutas del API, el webhook para pagos con Stripe y los servicios externos (PostgreSQL, Resend, Cloudinary). Mi recomendación: no te quedes solo con el gráfico, dale una leída al resto de la implementación propuesta antes de aprobar.

Build in parallel: multiagentes

Al momento de construir, Cursor ofrece dos opciones: Build normal o Build in parallel, que lanza múltiples agentes trabajando al mismo tiempo (lo que en otras herramientas se conoce como subagentes). Gasta más tokens, pero avanza mucho más rápido.

Con build in parallel, la interfaz cambia a modo multitask y en unos 15 minutos el plan completo estaba implementado. El resultado es un monorepo: en un mismo repositorio va el código del API (backend) y el frontend de Next.js.

Que Cursor pruebe su propio código: browser MCP

En lugar de levantar la aplicación y navegar manualmente, le pedimos a Cursor que la pruebe él mismo. Cursor tiene integrado un MCP para manipular el navegador, pero primero hay que configurar un par de cosas:

1. En Configuración → Agentes, activa Run mode → Run everything, para que el agente pueda ejecutar comandos sin preguntarte a cada rato.
2. En el sidebar, en Tools y MCPs → Browser automation, asegúrate de que Browser tab no esté en off, y marca la opción de mostrar enlaces de localhost dentro del navegador.

Con eso listo, delegamos la tarea:

Prueba el proyecto ejecutándolo y luego prueba el funcionamiento de todas las páginas usando el browser MCP de Cursor.

Un tip para no gastar tokens de más: si tienes activado el multitask, quítalo para este tipo de tareas. No necesitas múltiples agentes para probar páginas.

Cursor levanta el proyecto, abre una pestaña de browser y empieza a navegar por sí solo, probando cada página. Puedes tomar el control con Take control, pero sugiero esperar a que termine. Al final entrega un reporte con todas las páginas probadas, tanto de la web como del backend.

En otros videos he mostrado cómo instalar Playwright CLI, Chrome tools y otras herramientas para conectar con un agente. En Cursor esto ya viene integrado. Eso no significa que esas herramientas no sirvan: para testing masivo probablemente uses Playwright, y para testing en producción usaremos otra herramienta más adelante.

En este punto la aplicación funciona, con algunos detalles esperables: errores de hidratación menores y las integraciones externas en modo mock (simuladas), porque todavía no le hemos dado claves reales.

Mejorando la UI con skills

El landing generado funciona, pero no es excesivamente bonito. Para eso existen los skills: archivos markdown con reglas y guías de diseño escritas por alguien que sí sabe del tema, que el agente lee y aplica.

Dos sitios para encontrarlos:

• skills.sh — lanzado por Vercel (la misma empresa detrás de Next.js), con una enorme cantidad de skills: testing de navegadores, code review, diseño, etc.
• ui-skills — una lista mucho más filtrada, enfocada solo en frontend y diseño. Aquí están skills populares como impeccable, design love o UI Pro Max.

El que a mí me ha funcionado bastante bien, sobre todo para dashboards y aplicaciones SaaS, es interface design: mejora el diseño sin cambiarte el código exageradamente, mantiene la misma idea con mejoras puntuales.

Instalación

Copia el comando del skill y pégalo en la terminal integrada de Cursor (que ya está ubicada en tu proyecto). El instalador pregunta si quieres instalarlo a nivel de proyecto o global; recomiendo proyecto (con symlink), porque probablemente termines acumulando muchos skills. Esto crea una carpeta .skills en el proyecto, desde donde Cursor (y otras herramientas compatibles) lo pueden leer.

Uso

Puedes mencionarlo en el prompt, pero prefiero invocarlo explícitamente con slash:

/interface-design mejora la UI del dashboard y del landing

Y si quieres avanzar más rápido, activa el multitask para que lance varios subagentes revisando páginas en paralelo. En la parte inferior izquierda verás cuántos agentes están trabajando, y cada subagente tiene su propio resumen: es literalmente un chat dentro de otro chat, donde el principal delega a los secundarios.

El resultado no es radicalmente distinto, pero mejora colores, sombras en tarjetas y detalles de ese estilo. Y de nuevo, para verificar: "Comprueba el funcionamiento del dashboard usando el browser MCP de Cursor".

Sesiones en paralelo

Algo genial: no necesitas parar un test para seguir trabajando. Mientras un agente prueba el dashboard, puedes abrir otro chat y preguntar otra cosa. Además puedes renombrar cada tab (por ejemplo "credenciales", "investigación", "desarrollo") para saber qué hace cada sesión dentro del mismo proyecto.

Credenciales: qué necesita el proyecto para funcionar de verdad

En un chat aparte le pregunté:

¿Qué credenciales necesito darte para que funcione este proyecto en producción?

El agente lee los archivos y responde con la lista:

• Base de datos: un proveedor de PostgreSQL (Neon, Supabase… en nuestro caso lo delegamos a Railway más adelante).
• JWT secret: se puede generar con OpenSSL o al momento del despliegue.
• Stripe: secret key + webhook secret.
• Resend: API key para el envío de correos.
• Cloudinary: cloud name, API key y API secret para las imágenes.

Stripe: pagos y webhooks

Stripe es un procesador de pagos muy fácil de integrar. Si tu país no está soportado, no te preocupes: luego puedes pedirle a la IA que lo cambie por Mercado Pago, PayPal, Paddle o cualquier otro proveedor. Incluso puedes pedirle que investigue procesadores de pago disponibles en tu país, con costos, y cambiar la integración a partir de ahí.

Al crear tu cuenta, Stripe te da un entorno de prueba donde todas las transacciones son falsas. De ahí copiamos la clave secreta y se la pasamos al agente:

Este es el secret key de Stripe: [clave]. Actualiza el .env y comprueba los pagos usando el browser MCP de Cursor.

(Es posible que Cursor lance una alerta de seguridad pensando que le estás dando una clave de producción; es normal, es una clave de test.)

El agente prueba el checkout, corrige un error que aparece en el camino, llena los datos de tarjeta de prueba y confirma el pago con nuestra clave real de test.

¿Qué es un webhook y por qué lo necesitamos?

Cuando un usuario paga con Stripe, el formulario no habla con nuestro backend: los datos van directo a los servidores de Stripe, que son los que procesan el cobro. El problema es que nuestro servidor —el que tiene la base de datos de usuarios y órdenes— nunca se entera de que alguien pagó.

La solución es que Stripe notifique a nuestro servidor, y esa notificación es un webhook. El nombre viene de que invierte la comunicación típica de la web: normalmente el frontend le pide algo al backend y este responde. Con un webhook, nuestro servidor no pide nada; simplemente espera a que Stripe le avise cuando ocurre un evento: un pago, una desuscripción, un reembolso, un cambio de datos.

El problema del localhost (y cloudflared)

Para que Stripe nos notifique necesita una URL real, no localhost:3000. Podríamos subir a producción, pero aún no estamos en esa fase. Así que le pedimos al agente:

Crea una URL usando cloudflared.

cloudflared es un comando de terminal muy conocido que crea una URL pública con HTTPS que redirecciona a tu localhost. La mayoría de agentes lo conocen y, si no está instalado, lo descargan solos (esto depende del modelo: uno malo quizás te diga que no puede o te mande a configurar Cloudflare desde la web, que no es lo que queremos).

Con la URL pública lista, en Stripe vamos a Desarrolladores → Webhooks → Añadir un destino, elegimos Tu cuenta, seleccionamos el evento checkout.session.completed, pegamos la URL del webhook que nos dio el agente y creamos el destino. Stripe nos entrega un secreto de firma, que es el webhook secret que faltaba:

Este es el webhook secret: [clave]. Compruébalo con un pago usando el browser MCP de Cursor.

El agente hace todo el flujo de nuevo: elige productos, se registra, paga con datos de prueba… y como él mismo está observando el backend, confirma: Stripe notificó al API y la orden pasó de pendiente a pagado. Pagos listos.

Resend: correos transaccionales

Resend nos permite enviar correos cuando alguien compra: confirmación de compra, estado del pedido, etc. Es gratuito para probar.

1. Crea tu cuenta (puedes loguearte con GitHub).
2. En la sección API Keys, crea una nueva key con permisos de full access.
3. Pásasela al agente: "Esta es la clave de Resend: [clave]. Prueba el envío de correos al comprar un producto."

El agente hace una compra de prueba y, efectivamente, llega el correo: "Gracias por tu compra", con el ID de la orden y un enlace para acceder al libro comprado, que además aparece en la biblioteca personal del usuario.

Cloudinary: alojamiento de imágenes

Cloudinary es una plataforma para alojar archivos, principalmente imágenes y videos (aunque algunos guardan PDFs y otros archivos, está pensada para multimedia). La usaremos para las portadas de los libros que se suben desde el panel de control.

Necesitamos tres datos:

• Cloud name: aparece en el home de tu cuenta.
• API key y API secret: en Settings → API Keys puedes generar un par nuevo (rol master admin para tener acceso completo).

Se los pasamos al agente y le pedimos: "Prueba subiendo un archivo a Cloudinary." La prueba clásica es subir un píxel de unos 26 bytes; si devuelve la URL, la integración funciona.

Después implementamos la funcionalidad real. Un truco útil: copia la URL de la página donde falta la funcionalidad y pídele directamente:

En esta ruta [URL], implementa la subida de archivos con drag and drop; el archivo se sube a Cloudinary como portada del libro.

Y para probarlo, pega la imagen de un libro en el chat y dile: "Compruébalo y rellena tú mismo el resto de datos del formulario." El agente llena el formulario, sube la imagen, y esta aparece tanto en la aplicación como en los assets de Cloudinary.

Despliegue en Railway con CLI + skill

Para desplegar hay muchas opciones: Vercel, Railway, Render, o incluso un VPS. En este caso uso Railway porque se integra muy bien con IA: tiene un CLI que funciona en Linux, Windows y Mac, y además un skill oficial que le enseña al agente qué comandos existen y cómo usarlos.

Instalación

1. CLI: en la documentación de Railway están los comandos para cada sistema (en Windows, con WSL o alternativas como Scoop). Este se instala a nivel de todo el computador, así que cualquier proyecto lo puede usar.
2. Skill: recomiendo la instalación con npx skills, que es la forma genérica que funciona en cualquier agente. Igual que antes: proyecto o global, tú decides.

Un apunte: Railway también tiene un comando dedicado para configurar Cursor específicamente, pero prefiero el camino genérico. Si mañana usas otro editor —Antigravity, VS Code o el que sea— estos mismos pasos te sirven exactamente igual.

El despliegue

Primero hay que autenticarse desde la consola:

railway login

Esto abre el navegador para autorizar el acceso. Luego, en un chat nuevo:

/use-railway despliega todo este proyecto en Railway

Y aquí está lo genial: no hay que explicarle casi nada. Como ya tiene acceso al repositorio, analiza los archivos, el package.json, la base de datos que usa, y recrea todo en Railway: crea el proyecto, la instancia de PostgreSQL, el servicio del API y el de la aplicación web, con sus URLs de producción incluidas.

Eso sí: revisa lo que hace. A veces crea servicios de más o deja algún proyecto abandonado por ahí. Que sea automático no significa que no haya que entender lo que está pasando.

Ajustes post-despliegue

Al probar en producción quedaban pendientes: variables de entorno faltantes, datos mock en lugar de datos reales, y la conexión a la base de datos de Railway. Dos instrucciones lo resuelven:

Usa la red pública de PostgreSQL en Railway. Coloca las variables que ya tengo en local.

Si revisas el esquema del proyecto en Railway, en la sección de variables de cada servicio puedes verificar que estén todas: la dirección de la base de datos, la URL del frontend, el JWT, y las API keys de los servicios externos. Unos minutos después, la aplicación en producción funciona con login de admin y panel de control operativo.

Testing en producción con TestSprite

Ya en producción, el trabajo es comprobar que todo funcione de verdad. Para eso usé TestSprite, una plataforma de testing con IA para proyectos reales: entra a tu proyecto desplegado, lo prueba, te da un reporte e incluso graba en video los tests que ejecuta. Es como una combinación de framework de testing y agente de QA. Puedes probarlo gratis: al registrarte (con Gmail o GitHub) te dan 150 créditos sin necesidad de tarjeta.

Instalación del CLI

TestSprite tiene su propio CLI, y es incluso más fácil de instalar que los anteriores: son dos comandos que copias desde su GitHub y pegas en la terminal de Cursor. El segundo te pide un API key, que creas desde el sidebar de tu cuenta de TestSprite en la sección de API keys. La instalación además añade automáticamente los skills testsprite-verify y testsprite-onboard.

Ejecutando los tests

En un chat nuevo (para no entrar en conflicto con otras sesiones):

Testea este proyecto que está desplegado en Railway usando TestSprite CLI.

El agente detecta el skill de TestSprite, lo carga, y la plataforma empieza a analizar el proyecto y preparar tests. Lo importante: no los ejecuta en un entorno de pruebas, sino contra la URL de producción de Railway. Va paso a paso: que el homepage cargue, que el carrito funcione, que el login redirija correctamente.

Unos 15 minutos después, el reporte: tests que pasaron y tests bloqueados.

• Ejemplo de test que pasó: login de comprador con redirección a su biblioteca personal. Incluye el video del agente iniciando sesión y llegando a la biblioteca. Y no es solo video: cada paso está documentado y es editable, así que puedes intervenir en cualquiera (cambiar el email de prueba, la contraseña, etc.).
• Ejemplo de test bloqueado: "el homepage muestra el giro editorial y libros destacados". El agente buscó esa interfaz en el landing y no la encontró, así que el test falló.

Lo mejor es que el resultado también llega al código: en Cursor obtienes un resumen en tabla con el enlace al reporte web. Y como ya está en el chat, el mismo agente lo puede corregir:

Sí, añade los tests para el flujo de vendedor y admin, y corrige los tests que fueron bloqueados.

El ciclo se repite: actualiza código, añade tests, los ejecuta de uno en uno. Este proceso lo puedes correr en producción tantas veces como te alcancen los créditos (y en este ejemplo se gastó bastante poco).

Antes de recibir usuarios reales

Todo lo que hicimos usa credenciales de prueba. Para pasar a producción de verdad:

• Stripe: es lo único crítico. Repite el proceso de obtener el secret key y el webhook secret, pero con tu cuenta en modo producción, porque vas a querer cobrar de verdad.
• Base de datos: ya está en Railway, no hay nada que cambiar.
• Cloudinary: no es necesario cambiarla, todo se guarda en la misma cuenta.
• Resend: puedes mantener el mismo token o rotarlo si prefieres.

Conclusión

Con este flujo cubrimos el ciclo completo de un proyecto real: planificación con el modo Plan de Cursor, construcción con multiagentes, testing local con el browser MCP integrado, mejora de UI con skills, integración de servicios externos con sus credenciales de prueba, despliegue casi automático con el CLI y skill de Railway, y validación en producción con TestSprite.

La idea de fondo es delegar todo lo repetible: que el agente escriba, pruebe, despliegue y verifique, mientras tú te concentras en revisar, decidir y entender qué está pasando en cada paso. Porque esa es la otra lección del flujo: automático no significa a ciegas.