Creé una app completa de reservas médicas usando solo Cursor Composer 2.5

Con los precios de los modelos de IA subiendo cada vez más, Composer 2.5 —el modelo propio de Cursor— se ha vuelto una opción muy comentada: es rápido, barato y responde bastante bien para tareas puntuales de código. Así que decidí ponerlo a prueba de la forma más exigente posible: construir una aplicación real, de principio a fin, usando únicamente ese modelo.

El reto fue crear un sistema de reservas de citas médicas funcional, con pagos, base de datos, envío de correos, sincronización de calendario y despliegue en producción. Todo apoyándome en skills y MCPs dentro de Cursor para tener un entorno completo y crear la aplicación rápidamente.

En este artículo te muestro el paso a paso para que puedas replicarlo desde cero con cualquier agente de IA.

Qué vamos a construir

La aplicación tiene dos grandes flujos:

Lado del paciente: entra a un landing page, pulsa "agendar", se cargan las citas disponibles desde la base de datos, elige un médico, un día y una hora, coloca sus datos y el correo donde recibirá la confirmación, paga la reserva y recibe un mensaje de confirmación.

Lado del médico: un panel de control donde puede alterar su calendario, registrar más médicos, cambiar los horarios disponibles y ver los pagos registrados a lo largo de toda la web.

Para lograr esto integramos varios servicios:

• Next.js (App Router + Tailwind + shadcn/ui) para el frontend y las rutas de API
• Supabase como backend y base de datos
• PayPal para procesar los pagos (en modo sandbox)
• Resend para las confirmaciones por correo
• Google Calendar para sincronizar las citas (si el médico conecta su cuenta)
• Railway para el despliegue en producción

Es solo una demo, pero si la construyes puedes luego cambiar el procesador de pagos por cualquier otro, y todos estos servicios tienen plan gratuito para que sigas estos mismos pasos.

Paso 1: El prompt inicial y el modo Plan

Lo primero fue crear una carpeta (reservas-project), arrastrarla al editor y seleccionar Composer como modelo. Luego pegué un prompt describiendo el sistema: reservas de citas médicas con Next.js, App Router, Tailwind, shadcn/ui, Supabase como backend, PayPal para pagos y Resend para las confirmaciones de correo.

Como información adicional dentro del prompt detallé la estructura de datos:

• Una tabla médicos, para poder reservar con uno u otro
• Una tabla slots, para reservar la cita en una fecha concreta
• Un seed con datos de demostración

También describí el flujo del paciente (elige médico → día → hora → coloca datos → paga con PayPal → se crea la cita). Decidí no hacer que el paciente inicie sesión, porque eso implicaría crear roles; en su lugar recibe un correo de confirmación gracias a Resend.

El truco clave: antes de pedirle que construyera nada, cambié Cursor al modo Plan. Esto hace que el modelo elabore una planificación extensa de todo el proyecto y luego lo divida en tareas y fases, en lugar de lanzarse a escribir código a ciegas.

Composer respondió haciendo preguntas inteligentes:

• ¿Cómo deben acceder los médicos al panel? → con email y contraseña
• Si dos pacientes eligen el mismo horario a la vez, ¿quién gana? → quien pague primero

Tras confirmar, generó una lista completa de tareas: inicializar la app, crear la migración de la base de datos en Supabase, la configuración de horarios del médico y las rutas para integrar PayPal, Resend y Google Calendar (con OAuth). Como faltó mencionar el landing page, simplemente le pedí que añadiera uno minimalista y mobile-first con un botón para agendar.

Paso 2: Configurar el backend con Supabase y skills

En lugar de configurar el proyecto de Supabase clic a clic, usé los skills de Supabase. Un skill permite que el agente se conecte con tu herramienta de consola y configure todo el proyecto automáticamente, lo cual es mucho más cómodo.

Al ejecutar el comando de instalación, Cursor lanzó una ventana para escoger entre varios skills. Marqué el de PostgreSQL (con buenas prácticas) y el de Supabase (para controlar las configuraciones del backend), seleccioné Cursor como plataforma y se generó una carpeta .cursor/skills con todo dentro. No es código oculto: los skills quedan visibles ahí.

A partir de ese momento, escribiendo / y empezando a teclear "supabase" se autocompletaba el comando, señal de que ya estaba leyendo los skills. Le pedí entonces: configura el backend.

Un error común y cómo resolverlo

Aquí me topé con un problema típico: el modelo intentó conectarse a una base de datos local en lugar de a la nube. Detuve la ejecución y fui explícito: no uses la base local, usa el remoto.

El paso que faltaba era instalar el Supabase CLI. Tras instalarlo y ejecutar supabase login (que abre una ventana del navegador para pegar un código de verificación), le pedí que reintentara usando el CLI. Esta vez funcionó: creó el proyecto y, al revisar el dashboard, ahí estaban las tablas de citas, slots y médicos.

Las credenciales de demo no funcionaban al inicio porque no se había ejecutado el seed, así que le pedí: ejecuta los seeds con los usuarios demo. Después de eso, el inicio de sesión funcionó correctamente.

Composer es muy básico generando interfaces gráficas, pero lo que importa aquí es la funcionalidad, y eso lo resuelve rápido.

Paso 3: Conseguir las credenciales de cada servicio

El archivo .env.local necesitaba las claves de cada servicio. Importante: este archivo siempre debe mantenerse seguro, porque con él cualquiera puede conectarse a tus servicios.

Un truco muy práctico que usé en todo el proceso: en vez de pegar las claves manualmente (donde es fácil equivocarse), se las arrastraba al chat de Cursor o le pasaba el JSON de credenciales, y le decía "actualiza el .env.local". El agente las leía y las colocaba en su lugar mucho más rápido.

Resend (el más fácil)

Entras a resend.com, creas una cuenta (puedes usar GitHub o Google), vas a la sección de API Keys, creas una con acceso completo a todos los dominios y se la pasas a Cursor.

PayPal

Aquí hay que entrar a developer.paypal.com (no el dominio normal de PayPal). En la sección Apps & Credentials, lo más importante es asegurarte de estar en modo Sandbox, no Live. Creas una app y, al elegir el tipo:

• Merchant: para vender como una persona o tienda normal (esto es lo que necesitamos)
• Platform: para ser intermediario tipo marketplace, donde otros se registran a vender y tú cobras comisión

Eliges Merchant y obtienes un Client ID y un Secret Key, que le pasas a Cursor.

Google Calendar

Este es el más laborioso. Hay que configurar la pantalla de consentimiento de OAuth (nombre de la app, correo de contacto, marcar como usuarios externos para poder probar con cualquier cuenta de Google) y luego crear el cliente OAuth de tipo aplicación web.

El detalle crítico es la URI de redireccionamiento autorizado: debe coincidir exactamente con la ruta que generó Cursor en tu servidor local. Copias esa ruta desde el código, la pegas en Google Cloud, creas el cliente y obtienes tus claves (que también puedes descargar como JSON y arrastrar directamente a Cursor).

Paso 4: Probar el flujo completo en local

Con todas las claves en su lugar, reinicié el servidor de Next.js y empecé a probar:

1. Google Calendar: conecté mi cuenta, di permisos y apareció "Google Calendar conectado"
2. Reserva: elegí un médico, día y hora, coloqué los datos de un paciente de prueba y un motivo de consulta
3. Pago: al continuar con el pago se abrió la ventana de PayPal en modo sandbox

Para pagar en sandbox necesitas un usuario de prueba. En PayPal Developer, dentro de Testing Tools → Sandbox Accounts, ya vienen unos usuarios; si no, creas uno nuevo de tipo personal (que simula a tu cliente). Solo necesitas su email y contraseña para iniciar sesión y completar la compra.

Tras completar el pago aparecía "cita confirmada". Para recibir el correo de Resend hay un detalle importante en modo prueba: solo funciona enviando al correo propio de la cuenta de Resend hasta que verifiques un dominio en producción. Usando ese correo, la confirmación llegó perfectamente con la especialidad, la hora y el texto que había colocado.

Desde el acceso médico se ven todas las reservas registradas, confirmando que el flujo completo funciona de extremo a extremo.

Paso 5: Automatizar las pruebas con TestSprite

Todo lo que probé manualmente se puede automatizar. Para eso integré TestSprite, un MCP que usa IA para generar y ejecutar pruebas automáticas.

Un MCP es simplemente una herramienta extra que se le añade a una IA para que pueda usar una plataforma externa. Es como una extensión o plugin para tu agente.

El setup es sencillo: creas una cuenta gratuita en TestSprite (sin tarjeta), generas una API key y, como Cursor tiene un botón para añadir MCPs directamente, lo conectas en segundos. A partir de ahí el agente puede dar clics, probar la app y replicar esos tests para que los ejecutes una y otra vez.

Esto parece trivial en un proyecto pequeño, pero a medida que el proyecto crece se vuelve indispensable para garantizar que todo siga funcionando cuando añades nuevas características.

Paso 6: Desplegar en producción con Railway

Para el despliegue usé Railway. El skill correspondiente crea automáticamente el proyecto (en mi caso "Reservas Project") y carga el código.

Un par de puntos a tener en cuenta:

• Aunque diga que lo conecta con GitHub, no conecta el repo automáticamente: hay que dar clic en ese botón una vez desplegado
• Las variables de entorno se copian desde tu entorno local con el propio CLI (algunas habrá que adaptarlas)

Mi recomendación: en Settings → Repo, conecta tu repositorio (reservas-project) y pulsa Deploy. Así, cada vez que hagas push a GitHub, Railway redesplegará automáticamente. Finalmente, en la sección Networking obtienes la URL pública de la aplicación.

Al entrar a la URL en producción e iniciar sesión con el usuario administrador, vi exactamente la misma información que en local. ¿Por qué? Porque la base de datos está en Supabase y la app web simplemente la consume. Creé un médico nuevo desde producción y, al refrescar, aparecía también en el dashboard de Supabase. Luego repetí todo el flujo de reserva con PayPal y el correo de confirmación de Resend llegó sin problemas.

Mi veredicto sobre Composer 2.5

Después de construir todo esto desde una cuenta Pro nueva, estas son mis conclusiones:

Lo bueno:

• Responde muy rápido
• Funciona bien para tareas puntuales de código y escribir lógica
• Es un modelo barato, perfecto si buscas un editor accesible
• Combinado con otros modelos de Cursor, puedes crear bastantes proyectos

Lo no tan bueno:

• Las interfaces gráficas que genera son muy básicas
• Tiende a cometer errores como intentar conectarse a recursos locales

Lo colocaría bastante por detrás de Opus o GPT, pero se parece mucho al modelo Kimi —en el que de hecho está basado—. Con esta actualización, Cursor se vuelve una opción muy válida, sobre todo por lo accesible.

Un consejo final sobre el costo: en este proyecto ya sabía qué pedir y no me equivoqué mucho, así que el gasto fue contenido. Pero ten en cuenta que al usar IA es probable que necesites iterar una y otra vez, y es ahí donde se va el presupuesto.

Conclusión

Lo que parecía un simple proyecto de interfaz terminó integrando APIs de Google, Supabase, Resend y PayPal, con testing automatizado y despliegue en producción. Y todo con un modelo rápido y económico.

La lección más importante: con las herramientas correctas —skills, MCPs y un buen flujo de trabajo— puedes construir aplicaciones completas y reales mucho más rápido de lo que imaginas, sin importar qué agente de IA uses.

¿Tienes una idea de qué te gustaría construir a continuación? Déjalo en los comentarios.

Si quieres llevar tus proyectos al siguiente nivel, en fazt.dev puedes reservar asesorías personalizadas sobre cualquier tema.