Vibecodea tu primera app en una tarde

---
name: despliegue
description: que exista en internet, con dominio, y que siga existiendo mañana.
---

# Despliegue

Instrucciones para el agente que está construyendo esta app. Sigue esta skill cuando
pongas la app en línea, configures dominio, variables de entorno o monitoreo.

## Cuándo usar esta skill

Actívala en cuanto se cumpla cualquiera de estas condiciones:

- Alguien que no eres tú tiene que abrir la app.
- Necesitas dominio propio, HTTPS y una URL estable para compartir.
- Hay secretos (llaves de API, base de datos) que no pueden vivir en el repo.
- Quieres enterarte de los errores antes de que te los reporten.

Este es el paso que separa una carpeta en tu máquina de algo que alguien más puede usar,
y también donde una réplica "gratis" empieza a costar dinero de verdad.

## Cómo construirla

Usa este stack salvo que el proyecto ya tenga otro decidido: **Vercel** o **Railway**
para la app, Postgres administrado aparte, secretos en el panel del proveedor, un
contenedor propio solo si el trabajo es pesado y constante.

1. Despliegue desde Git: cada push a `main` publica, cada rama abre una vista previa.
2. Variables de entorno en el proveedor, con `.env.example` versionado. Ningún secreto
   en el repo, nunca.
3. Dominio propio y HTTPS desde el inicio: cookies, OAuth y correo dependen del dominio
   final, así que no lo dejes para el último día.
4. Base de datos administrada con respaldos automáticos y restauración probada al menos
   una vez.
5. Agrega registro de errores (**Sentry** o el del proveedor) y una alerta a tu correo o
   Telegram.
6. Deja escrito en el README cómo correrlo en local y cómo desplegarlo. Tu yo de dentro
   de seis meses lo va a necesitar.

## En qué te vas a trabar

- **Las funciones sin servidor tienen tiempo límite:** nada de procesos largos ahí, van a
  segundo plano (cola, cron, worker).
- **Los planes gratuitos duermen, limitan conexiones o cortan ancho de banda** justo
  cuando llega gente. Revisa los límites del plan antes de anunciar el lanzamiento.
- **El costo real de una réplica suma base de datos, almacenamiento, correo y llamadas a
  modelos.** Súmalos antes de prometer que sale gratis.

## Criterio de terminado

No declares el despliegue listo hasta que un push a `main` publique solo, una rama nueva
abra su propia vista previa, y una alerta de error de prueba te llegue de verdad.

---
name: integraciones-y-webhooks
description: conectar tu app con las demás, en los dos sentidos.
---

# Integraciones y webhooks

Instrucciones para el agente que está construyendo esta app. Sigue esta skill cuando
consumas APIs ajenas, recibas webhooks entrantes, emitas los tuyos o programes tareas.

## Cuándo usar esta skill

Actívala en cuanto se cumpla cualquiera de estas condiciones:

- Tu app tiene que leer o escribir en Google, Slack, Notion, GitHub o similares.
- Algo de afuera debe avisarte cuando ocurre un evento (un pago, un mensaje, un commit).
- Hay trabajo que debe correr cada hora o cada noche sin que nadie lo dispare.
- Estás replicando una herramienta de automatización, publicación o sincronización.

Esta es el moat más citado del cementerio: el producto original no gana por su pantalla,
gana porque ya habla con Slack, Google Calendar, Stripe y otras cuarenta cosas, y porque
alguien las repara cada semana. Trátalo con esa seriedad.

## Cómo construirla

Usa este stack salvo que el proyecto ya tenga otro decidido: OAuth2 con tokens cifrados
en base de datos, endpoints de webhook idempotentes, **Vercel Cron** o **GitHub Actions**
programadas para lo periódico, **Inngest** o **BullMQ** solo cuando el volumen lo pida.

1. Integra un servicio, completo y bien, antes de intentar cinco a medias. La segunda
   integración te va a enseñar dónde abstraer, la primera todavía no.
2. Guarda access token y refresh token cifrados, con su fecha de expiración, y renuévalos
   antes de que caduquen.
3. Todo webhook entrante: verifica la firma, responde 200 rápido y procesa después. Si
   tardas, te reenvían el evento.
4. Haz el procesamiento idempotente por id de evento. Los duplicados no son una
   excepción, son la norma.
5. Para lo programado, empieza con un cron del proveedor (Vercel Cron, GitHub Actions) y
   una tabla de trabajos en Postgres. Solo agrega Inngest, Trigger.dev o BullMQ cuando
   esa tabla se te quede corta.
6. Registra cada llamada saliente fallida con su respuesta: sin ese registro, depurar una
   integración es adivinar.

## En qué te vas a trabar

- **Cada API cambia límites, alcances y políticas por su cuenta.** Las integraciones no
  se terminan, se mantienen; avísalo si te preguntan cuánto falta.
- **La revisión de app de Google o Slack puede tardar semanas** y pedir cosas que no
  anticipaste. Empieza ese trámite temprano, no al final.
- **Los límites de tasa se sienten hasta que tienes usuarios.** Agrupa peticiones y
  guarda en caché desde el inicio, no cuando llegue el primer 429.

## Criterio de terminado

No declares una integración lista hasta que sobreviva un webhook duplicado sin efecto
doble, un token expirado se renueve solo, y una llamada saliente fallida quede registrada
en vez de perderse en silencio.

---
name: tareas-programadas-y-colas
description: hacer trabajo después, reintentarlo y saber cuándo dejó de funcionar.
---

# Tareas programadas y colas

Instrucciones para el agente que está construyendo esta app. Sigue esta skill cuando el
trabajo no deba terminar dentro de una petición web o tenga que ocurrir en el futuro.

## Cuándo usar esta skill

Actívala en cuanto se cumpla cualquiera de estas condiciones:

- Generas archivos, importas datos, envías lotes o llamas una API lenta.
- Algo debe correr cada hora, cada noche o en una fecha elegida por el usuario.
- Un fallo temporal debe reintentarse sin que la persona repita la acción.
- Necesitas limitar concurrencia o respetar la tasa de un proveedor externo.

Si el trabajo tarda milisegundos y no tiene efectos externos, ejecútalo en la petición.
Una cola agrega operación; úsala porque necesitas sus garantías, no por arquitectura.

## Cómo armarla

Usa **pg-boss sobre Postgres** con un worker siempre activo. Si el proyecto es totalmente
serverless, usa **Inngest** o **Trigger.dev** y conserva las mismas reglas de idempotencia.

1. El endpoint valida, guarda el cambio de negocio y encola un id de recurso. No metas
   documentos completos ni secretos en el payload.
2. Define por tipo de job: esquema versionado, timeout, máximo de intentos, concurrencia
   y llave de idempotencia. Rechaza payloads con una versión desconocida.
3. Haz cada handler idempotente. Antes de cobrar, enviar o crear, busca el efecto por su
   llave; marca terminado solo después de confirmar el resultado externo.
4. Reintenta errores temporales con espera exponencial y jitter. Manda errores
   permanentes a fallidos de inmediato y conserva una cola muerta operable.
5. Usa leases o visibilidad con vencimiento para recuperar trabajos de un worker caído.
   Asume entrega al menos una vez, nunca exactamente una vez.
6. Haz que el cron solo encole. Usa UTC para disparadores del sistema y guarda la zona
   IANA cuando el horario pertenece a una persona o negocio.
7. Registra espera, duración, intentos, error y correlación. Alerta por edad del job más
   viejo y por crecimiento de fallidos, no solo por CPU.
8. Agrega cancelar y reintentar desde una vista protegida. Reintentar debe conservar la
   llave original o declarar explícitamente una nueva operación.

## En qué te vas a trabar

- **El worker muere a mitad del efecto externo.** Por eso el handler consulta antes de
  repetir y el proveedor recibe una llave de idempotencia cuando la soporta.
- **Un cron puede dispararse dos veces o no dispararse.** Pon un registro único por
  periodo y un reconciliador que encuentre ejecuciones faltantes.
- **Los jobs viejos cambian de forma cuando despliegas código nuevo.** Versiona payloads
  y mantén un adaptador mientras quede trabajo con la versión anterior.
- **La cola también cuesta.** Mide retención, Redis o Postgres, workers encendidos y
  llamadas reintentadas antes de vender procesamiento ilimitado.

## Qué NO hacer

- No uses `setTimeout` en un proceso web para trabajo importante.
- No reintentes sin límite ni a intervalos fijos contra un proveedor caído.
- No guardes tokens, archivos binarios o datos personales innecesarios en el payload.
- No marques el job terminado antes de persistir el efecto que el usuario espera.

## Checklist

- [ ] Cada tipo de job tiene esquema, timeout, intentos, concurrencia e idempotencia.
- [ ] Un worker que muere a mitad del proceso no pierde ni duplica el efecto.
- [ ] Cron duplicado y cron omitido tienen pruebas y reconciliación.
- [ ] Errores permanentes llegan a una cola muerta visible y reintentable.
- [ ] Métricas y alertas cubren espera, duración, fallos y edad del trabajo más viejo.
- [ ] Los horarios del usuario conservan su zona IANA y los del sistema usan UTC.
- [ ] Un despliegue nuevo puede procesar payloads antiguos todavía en cola.

---
name: pagos-y-suscripciones
description: cobrar todos los meses sin perseguir a nadie.
---

# Pagos y suscripciones

Instrucciones para el agente que está construyendo esta app. Sigue esta skill cuando
toques checkout, planes, prueba gratis, cancelaciones o el estado de cuenta que decide
qué puede usar cada quien.

## Cuándo usar esta skill

Actívala en cuanto se cumpla cualquiera de estas condiciones:

- Quieres cobrar por la versión que estás construyendo, no solo usarla tú.
- Hay funciones que solo deben existir en un plan de paga.
- Vendes por asiento, por uso o con prueba gratuita.
- Necesitas facturas, impuestos o comprobantes para tus clientes.

Cobrar una vez es fácil; lo difícil es que tu base de datos y la del proveedor de pagos
digan lo mismo después de un pago fallido, un cambio de plan a medio mes o un reembolso.

## Cómo construirla

Usa este stack salvo que el proyecto ya tenga otro decidido: **Stripe Checkout +
Customer Portal**, o **Lemon Squeezy** / **Paddle** si prefieres que ellos sean el
comerciante registrado.

1. No construyas formularios de tarjeta. Redirige a Checkout alojado y vuelve con una
   sesión.
2. Guarda solo tres cosas de tu lado: `customerId`, `subscriptionId` y estado del plan.
   El proveedor es la fuente de la verdad del dinero, no tu tabla.
3. Deriva los permisos del estado (`active`, `trialing`, `past_due`, `canceled`), nunca
   de "pagó una vez".
4. Escucha los webhooks de suscripción y hazlos idempotentes: llegan repetidos y
   desordenados.
5. Manda a Customer Portal para cambios de plan, tarjeta y cancelación. Es la pantalla
   que menos vale la pena rehacer tú mismo.
6. Prueba con tarjetas de fallo: pago rechazado, disputa y reembolso. Ese es el camino
   que rompe la app en producción.

## En qué te vas a trabar

- **Impuestos y facturación son el moat real:** IVA, retenciones y comerciante
  registrado no son código, son cumplimiento. No los subestimes por ser "solo un
  webhook".
- **Si tu webhook falla en silencio, la gente paga y no recibe acceso.** Alerta cuando
  falle, no dejes que lo descubra el cliente.
- **Prorrateos y cambios de plan a medio ciclo son la fuente número uno de facturas
  equivocadas.** Prueba ese camino explícitamente, no solo el flujo feliz.

## Criterio de terminado

No declares esto listo hasta que un pago rechazado, una disputa y un reembolso pasen por
el sistema completo sin dejar al usuario con acceso equivocado, y hasta que el estado de
tu base de datos coincida con el de Stripe después de cada webhook de prueba.

---
name: analitica-de-producto
description: saber qué usa la gente antes de construir lo siguiente.
---

# Analítica de producto

Instrucciones para el agente que está construyendo esta app. Sigue esta skill cuando
agregues registro de eventos, conteo de visitas o cualquier tablero de métricas.

## Cuándo usar esta skill

Actívala en cuanto se cumpla cualquiera de estas condiciones:

- Alguien más que tú ya usa la app y quieres saber si vuelve.
- Necesitas ver dónde abandona la gente el registro o el checkout.
- Vas a decidir qué construir después y no quieres decidirlo por intuición.
- Estás replicando una herramienta cuyo producto es justamente el tablero de métricas.

Si ninguna aplica, no instrumentes nada todavía: medir poco y bien vale más que medir
por si acaso.

## Cómo construirla

Usa este stack salvo que el proyecto ya tenga otro decidido: **Plausible** o **Umami**
autoalojado para páginas, más una tabla de eventos propia en **Postgres** para lo que
importa del producto.

1. Escribe primero las cinco preguntas que quieres responder. Los eventos salen de ahí,
   no al revés.
2. Analítica de páginas con una herramienta sin cookies (Plausible o Umami): menos aviso
   legal, menos peso, suficiente para tráfico.
3. Eventos de producto en tu propia tabla: nombre, usuario, organización, propiedades en
   JSON, fecha. Es una tabla, no una plataforma.
4. Fija una convención de nombres (`objeto_accion`) y documéntala en el repo el primer
   día, antes de que existan diez nombres distintos para lo mismo.
5. Arma las vistas agregadas con SQL y guárdalas como consultas versionadas o vistas
   materializadas, no como clics sueltos en un dashboard externo.
6. Nunca guardes datos personales en las propiedades del evento: id de usuario sí, correo
   no.

## En qué te vas a trabar

- **Los bloqueadores de anuncios se comen buena parte de los eventos del cliente.** Lo
  importante se registra en el servidor, no confíes solo en JavaScript del navegador.
- **Un tablero con veinte gráficas es un tablero que nadie lee.** Tres números y un
  embudo bastan; resiste la tentación de agregar una gráfica más.
- **Rastrear sin base legal ni aviso de privacidad es un problema, no una funcionalidad.**
  Revísalo antes de mandar el primer evento a producción.

## Criterio de terminado

No declares la analítica lista hasta que puedas responder, con datos reales y no con
intuición, las cinco preguntas que escribiste al inicio, y hasta que el tablero quepa en
una sola pantalla sin hacer scroll.

---
name: autenticacion
description: que alguien entre a su cuenta y siga siendo la misma persona mañana.
---

# Autenticación

Instrucciones para el agente que está construyendo esta app. Sigue esta skill cuando
toques registro, inicio de sesión, sesiones o recuperación de contraseña.

## Cuándo usar esta skill

Actívala en cuanto se cumpla cualquiera de estas condiciones:

- La app guarda algo que pertenece a una persona y no a todo el mundo.
- Se va a cobrar: sin cuenta no hay a quién cobrarle ni qué desbloquear.
- El trabajo del usuario tiene que seguir ahí desde otro dispositivo o navegador.
- Hay un panel, un historial o una configuración que no debe ser pública.

Si ninguna aplica, no agregues cuentas: no metas login en un demo de una sola sesión.

## Cómo construirla

Usa este stack salvo que el proyecto ya tenga otro decidido: **Better Auth** (o Lucia)
sobre **Postgres**, sesiones en cookie `httpOnly`, correo transaccional por **Resend**.
No escribas tu propia capa de criptografía de sesión.

1. Modela tres tablas: `users`, `sessions` y `accounts` (proveedores OAuth). Usa el
   esquema que la librería ya define; no inventes uno propio.
2. Arranca solo con correo + contraseña. Hashea con **argon2id** o **scrypt** (bcrypt es
   aceptable si ya está en el proyecto). Nunca guardes la contraseña en claro y nunca la
   mandes por correo.
3. Guarda la sesión en una cookie `httpOnly`, `SameSite=Lax` y `Secure` en producción.
   Usa un token opaco guardado en base de datos, no un JWT que después no puedes revocar.
4. Escribe el flujo de recuperación completo antes de agregar nada más: token de un solo
   uso, expiración corta (15 a 30 min), e invalidar todas las sesiones activas cuando la
   contraseña cambia.
5. Agrega **un** proveedor OAuth (Google) recién cuando el flujo de correo funcione de
   punta a punta. Uno, no cinco.
6. Pon límite de intentos por IP y por correo en `login` y en `forgot-password`.
7. Deja los secretos en `.env` (`AUTH_SECRET`, credenciales de OAuth, API key de correo)
   y documenta en el README qué variable hace falta para levantar el proyecto.

## En qué te vas a trabar

- **El correo transaccional es el cuello de botella real.** Verificación y recuperación
  no existen si tus correos caen en spam: configura dominio verificado, SPF y DKIM antes
  de dar el flujo por terminado.
- **OAuth se ve gratis hasta que lo pruebas.** Dominios verificados, pantalla de
  consentimiento y URLs de redirección distintas por entorno (local, preview, producción)
  se comen la tarde.
- **Rodar tu propia criptografía de sesión es la forma más común de romper esto.** Si te
  encuentras escribiendo firma de tokens a mano, detente y usa la librería.

## Criterio de terminado

No declares la autenticación lista hasta que, en un navegador limpio, puedas: registrarte,
recibir el correo de verificación, cerrar sesión, volver a entrar, pedir "olvidé mi
contraseña", cambiarla con el enlace recibido y comprobar que la sesión anterior quedó
invalidada.

---
name: despliegue
description: que exista en internet, con dominio, y que siga existiendo mañana.
---

# Despliegue

Instrucciones para el agente que está construyendo esta app. Sigue esta skill cuando
pongas la app en línea, configures dominio, variables de entorno o monitoreo.

## Cuándo usar esta skill

Actívala en cuanto se cumpla cualquiera de estas condiciones:

- Alguien que no eres tú tiene que abrir la app.
- Necesitas dominio propio, HTTPS y una URL estable para compartir.
- Hay secretos (llaves de API, base de datos) que no pueden vivir en el repo.
- Quieres enterarte de los errores antes de que te los reporten.

Este es el paso que separa una carpeta en tu máquina de algo que alguien más puede usar,
y también donde una réplica "gratis" empieza a costar dinero de verdad.

## Cómo construirla

Usa este stack salvo que el proyecto ya tenga otro decidido: **Vercel** o **Railway**
para la app, Postgres administrado aparte, secretos en el panel del proveedor, un
contenedor propio solo si el trabajo es pesado y constante.

1. Despliegue desde Git: cada push a `main` publica, cada rama abre una vista previa.
2. Variables de entorno en el proveedor, con `.env.example` versionado. Ningún secreto
   en el repo, nunca.
3. Dominio propio y HTTPS desde el inicio: cookies, OAuth y correo dependen del dominio
   final, así que no lo dejes para el último día.
4. Base de datos administrada con respaldos automáticos y restauración probada al menos
   una vez.
5. Agrega registro de errores (**Sentry** o el del proveedor) y una alerta a tu correo o
   Telegram.
6. Deja escrito en el README cómo correrlo en local y cómo desplegarlo. Tu yo de dentro
   de seis meses lo va a necesitar.

## En qué te vas a trabar

- **Las funciones sin servidor tienen tiempo límite:** nada de procesos largos ahí, van a
  segundo plano (cola, cron, worker).
- **Los planes gratuitos duermen, limitan conexiones o cortan ancho de banda** justo
  cuando llega gente. Revisa los límites del plan antes de anunciar el lanzamiento.
- **El costo real de una réplica suma base de datos, almacenamiento, correo y llamadas a
  modelos.** Súmalos antes de prometer que sale gratis.

## Criterio de terminado

No declares el despliegue listo hasta que un push a `main` publique solo, una rama nueva
abra su propia vista previa, y una alerta de error de prueba te llegue de verdad.

---
name: onboarding-y-limites-por-plan
description: llevar a la primera victoria y cobrar por límites que el servidor sí aplica.
---

# Onboarding y límites por plan

Instrucciones para el agente que está construyendo esta app. Sigue esta skill cuando
armes trial, activación inicial, cuotas, feature flags o pantallas de upgrade.

## Cuándo usar esta skill

Actívala en cuanto se cumpla cualquiera de estas condiciones:

- Una cuenta nueva necesita datos o configuración antes de obtener valor.
- Hay prueba gratuita, plan gratis o más de un plan pagado.
- Cobras por usuarios, proyectos, almacenamiento, uso o funciones.
- Necesitas lanzar una función a un grupo sin desplegar otra versión.

Si todos reciben el mismo producto y no cobras, crea un estado vacío excelente. No
construyas un motor de entitlements porque algún día podría haber planes.

## Cómo armarla

Usa **Postgres** como fuente de verdad para onboarding y entitlements. Mantén flags
operativos en configuración versionada; agrega **PostHog feature flags** solo si ya usas
PostHog y necesitas rollout gradual.

1. Define una sola “primera victoria” medible, como publicar, importar, cobrar o invitar.
   Diseña el onboarding hacia ese evento, no hacia completar un tour.
2. Guarda pasos por cuenta con `completedAt`, versión y actor. Deriva lo que puedas de
   acciones reales; no marques “conectó calendario” porque cerró un modal.
3. Separa tres conceptos: producto contratado, estado de cobro y entitlements efectivos.
   Un webhook actualiza suscripción; una función central resuelve `puedeUsar` y `limiteDe`.
4. Define planes y límites con slugs estables. Guarda nombres y copy aparte para poder
   cambiar marketing sin romper permisos históricos.
5. Aplica límites en una transacción del servidor. Antes de crear, cuenta o reserva uso;
   la UI solo explica el resultado, nunca es la barrera real.
6. Calcula trial con fechas del servidor y una política explícita al vencer. Conserva la
   información en modo lectura cuando sea razonable; no borres trabajo para forzar upgrade.
7. Muestra el consumo antes del límite y explica qué acción lo reduce. Un upgrade modal
   debe decir qué se agotó, cuánto incluye el plan y qué pasa al bajar de plan.
8. Instrumenta inicio, primera victoria, abandono y upgrade. Revisa el embudo por canal y
   plan sin guardar datos personales en eventos.

## En qué te vas a trabar

- **Pago activo no equivale a permiso.** Asientos extra, add-ons, créditos y periodos de
  gracia exigen una capa de entitlements separada del nombre del plan.
- **Los contadores compiten.** Dos peticiones simultáneas pueden rebasar una cuota; usa
  bloqueo, contador atómico o reserva con expiración.
- **Bajar de plan deja exceso existente.** Define por recurso si bloqueas nuevas altas,
  pones solo lectura o programas eliminación; comunícalo antes del cambio.
- **Un trial tiene costo variable.** Limita modelos, SMS, almacenamiento y otros recursos
  medidos aunque la tarjeta todavía no exista.

## Qué NO hacer

- No disperses `plan === "pro"` por componentes y endpoints.
- No confíes en esconder botones para aplicar cuotas.
- No reinicies trials al cambiar correo, organización o proveedor OAuth.
- No bloquees exportación o cancelación para presionar una mejora de plan.

## Checklist

- [ ] La primera victoria tiene evento y se alcanza sin completar pasos decorativos.
- [ ] Onboarding, cobro y entitlements tienen estados separados.
- [ ] Una función central decide funciones y límites para todos los endpoints.
- [ ] Dos peticiones simultáneas no rebasan una cuota.
- [ ] Trial vencido, pago atrasado, upgrade y downgrade tienen pruebas.
- [ ] La persona ve consumo, límite y consecuencia antes de llegar al bloqueo.
- [ ] Exportar, cancelar y recuperar datos no dependen de aceptar un upgrade.

---
name: pagos-y-suscripciones
description: cobrar todos los meses sin perseguir a nadie.
---

# Pagos y suscripciones

Instrucciones para el agente que está construyendo esta app. Sigue esta skill cuando
toques checkout, planes, prueba gratis, cancelaciones o el estado de cuenta que decide
qué puede usar cada quien.

## Cuándo usar esta skill

Actívala en cuanto se cumpla cualquiera de estas condiciones:

- Quieres cobrar por la versión que estás construyendo, no solo usarla tú.
- Hay funciones que solo deben existir en un plan de paga.
- Vendes por asiento, por uso o con prueba gratuita.
- Necesitas facturas, impuestos o comprobantes para tus clientes.

Cobrar una vez es fácil; lo difícil es que tu base de datos y la del proveedor de pagos
digan lo mismo después de un pago fallido, un cambio de plan a medio mes o un reembolso.

## Cómo construirla

Usa este stack salvo que el proyecto ya tenga otro decidido: **Stripe Checkout +
Customer Portal**, o **Lemon Squeezy** / **Paddle** si prefieres que ellos sean el
comerciante registrado.

1. No construyas formularios de tarjeta. Redirige a Checkout alojado y vuelve con una
   sesión.
2. Guarda solo tres cosas de tu lado: `customerId`, `subscriptionId` y estado del plan.
   El proveedor es la fuente de la verdad del dinero, no tu tabla.
3. Deriva los permisos del estado (`active`, `trialing`, `past_due`, `canceled`), nunca
   de "pagó una vez".
4. Escucha los webhooks de suscripción y hazlos idempotentes: llegan repetidos y
   desordenados.
5. Manda a Customer Portal para cambios de plan, tarjeta y cancelación. Es la pantalla
   que menos vale la pena rehacer tú mismo.
6. Prueba con tarjetas de fallo: pago rechazado, disputa y reembolso. Ese es el camino
   que rompe la app en producción.

## En qué te vas a trabar

- **Impuestos y facturación son el moat real:** IVA, retenciones y comerciante
  registrado no son código, son cumplimiento. No los subestimes por ser "solo un
  webhook".
- **Si tu webhook falla en silencio, la gente paga y no recibe acceso.** Alerta cuando
  falle, no dejes que lo descubra el cliente.
- **Prorrateos y cambios de plan a medio ciclo son la fuente número uno de facturas
  equivocadas.** Prueba ese camino explícitamente, no solo el flujo feliz.

## Criterio de terminado

No declares esto listo hasta que un pago rechazado, una disputa y un reembolso pasen por
el sistema completo sin dejar al usuario con acceso equivocado, y hasta que el estado de
tu base de datos coincida con el de Stripe después de cada webhook de prueba.