Antes de lanzar esa app vibe-codeada

Si estás construyendo con Lovable, Base44, Replit, Bolt, Cursor, Claude Code, Codex o cualquier herramienta asistida por IA, el objetivo no es dejar de hacer vibe coding. El objetivo es saber cuándo un prototipo rápido cruzó la línea y se convirtió en un producto que puede lastimar usuarios, perder ingresos o bloquear la próxima decisión de negocio.

Una landing con datos falsos es un prototipo. Un producto con usuarios reales, autenticación, datos privados, pagos, emails, acceso admin y deploy en producción es otra responsabilidad.

Esta checklist es para ese momento.

Ya escribimos sobre los costos ocultos de los productos vibe-codeados, el problema del MVP auto de Homero y cómo auditar un codebase generado con IA antes de escalar. Este post es más táctico: ¿qué debería revisar un vibecoder antes de dejar que usuarios reales dependan de la app?

La regla: la pantalla termina antes que el sistema

El vibe coding hace que la capa visible aparezca temprano. Los botones funcionan. Las páginas cargan. El dashboard parece real. La demo convence.

Pero las partes invisibles suelen decidir si el producto está listo para lanzarse:

• quién puede acceder a qué datos
• qué pasa cuando un pago falla
• dónde se guardan los secretos
• cómo la base de datos representa ownership
• si producción puede volver atrás después de un mal deploy
• si el equipo puede debuggear un recorrido roto

Por eso esta checklist no se trata de agregar más features. Se trata de revisar el producto invisible antes de que el producto visible haga una promesa.

Si usás Lovable, Base44, Replit o plataformas similares

Estas plataformas son muy buenas para avanzar rápido, pero la velocidad puede esconder problemas de ownership. No le pidas solamente a la plataforma que construya la próxima pantalla. Pedile que explique el sistema que ya creó.

Prompts útiles:

• "Mostrame todos los lugares donde se guardan secrets, API keys, tokens o service role keys. Decime cuáles quedan expuestos al navegador."
• "Explicame cómo se protegen las rutas. ¿Qué chequeos pasan solo en la UI y cuáles pasan en el servidor?"
• "Mapeá las tablas de la base de datos y explicame quién es dueño de cada registro. Mostrame cómo se evita que un usuario lea datos de otro."
• "Listá todos los eventos de pago que esta app maneja y todos los eventos de pago que ignora."
• "Decime cómo subir este proyecto a GitHub y qué archivos no deberían commitearse."
• "Creá una checklist de producción para auth, pagos, base de datos, variables de entorno y rollback."

Si la respuesta es vaga, esa es la señal. Un producto real necesita más que pantallas generadas; necesita un sistema que puedas explicar.

1. Autenticación: no inventes tu propio login

La autenticación es uno de esos lugares donde muchas apps generadas con IA se ven bien en pantalla, pero fallan en los detalles.

Si tu app tiene cuentas, dashboards privados, suscripciones, paneles admin, portales para clientes o datos específicos por usuario, necesitás una autenticación aburrida, estándar y difícil de saltear por accidente.

Usá un proveedor confiable o un framework maduro. Supabase Auth, Clerk, Auth0, Firebase Auth, Cognito, NextAuth y herramientas similares existen por una razón. Lo riesgoso es pedirle a la IA que "arme el login" desde cero y aceptar cualquier lógica de tokens, cookies, passwords o sesiones que invente.

Antes de lanzar, revisá:

• ¿Un usuario puede ver datos de otro cambiando un ID en la URL?
• ¿Las rutas admin están protegidas en el servidor, no solo escondidas en la UI?
• ¿Las sesiones expiran correctamente después de cerrar sesión?
• ¿Los links de recuperación de contraseña son de un solo uso y tienen vencimiento?
• ¿Los roles están claros, por ejemplo user, admin, owner o support?
• ¿Un usuario eliminado, dado de baja o impago puede seguir entrando a zonas privadas?

La regla más importante: la UI no es seguridad. Esconder un botón no protege una ruta. Deshabilitar un menú no protege una API. Cada permiso importante tiene que validarse en el backend o en la política de la base de datos.

Receta rápida: sanity check de auth

1. Creá dos usuarios normales.
2. Creá datos privados con el usuario A.
3. Iniciá sesión como usuario B.
4. Intentá acceder al registro del usuario A cambiando la URL, el request body o el ID.
5. Repetí el mismo chequeo para pantallas admin y funcionalidades pagas.

Si el usuario B puede ver o modificar algo del usuario A, frená y corregí autorización antes de lanzar.

2. Seguridad: secretos, permisos y validación del lado servidor

Un error común en productos vibe-codeados es poner claves secretas donde el navegador puede verlas. Si una API key, service role key, webhook secret, token privado, credencial de base de datos o secreto de pagos aparece en el frontend, ya no es secreto.

Antes de lanzar, buscá secretos en:

• archivos frontend
• ejemplos de .env
• archivos de configuración generados
• build público
• commits de GitHub
• paneles de ambiente en Replit o plataformas similares
• screenshots o prompts copiados

Después revisá qué cosas confía la app. El código generado por IA suele confiar en el camino feliz: "el frontend mandó un user ID válido, entonces debe ser cierto". No alcanza. El backend debería validar el usuario, la acción, el input y el permiso cada vez.

Preguntate:

• ¿El backend valida campos requeridos, tipos, formatos y límites?
• ¿Los uploads tienen límites de tamaño, tipo y destino?
• ¿Las escrituras en base de datos están limitadas al usuario u organización autenticada?
• ¿Las rutas públicas son intencionalmente públicas o quedaron expuestas sin querer?
• ¿Los callbacks de terceros se verifican antes de actualizar la base de datos?

La seguridad no necesita ser dramática. Mucho riesgo temprano viene de errores simples: credenciales expuestas, permisos débiles, validación faltante y código generado que asume que nadie va a probar la URL incorrecta.

Receta rápida: chequeo de secretos expuestos

Pedile a tu herramienta de IA o agente de código:

Buscá en el codebase API keys, service role keys, URLs de base de datos, webhook secrets, secretos de pago y tokens privados. Separá los resultados entre uso seguro del lado servidor y uso inseguro expuesto al navegador. Explicá qué debería moverse a variables de entorno o código solo de backend.

Después revisá manualmente el build público y el historial de GitHub. Un secreto no vuelve a ser seguro solo porque lo borraste del último archivo.

3. Base de datos: tu modelo es la memoria del producto

Las herramientas de IA son muy buenas creando tablas rápido. Eso no significa que el modelo represente bien tu negocio.

Una base frágil suele aparecer después como confusión de producto: usuarios duplicados, ownership perdido, registros huérfanos, suscripciones que no coinciden con cuentas, proyectos sin dueño, entidades borradas que siguen apareciendo en reportes o dashboards que no pueden responder preguntas básicas del negocio.

Antes de lanzar, mapeá los objetos principales en lenguaje simple:

• ¿Quién es dueño de este registro?
• ¿Puede pertenecer a un equipo, empresa o workspace, o solo a un usuario?
• ¿Qué pasa si se borra el dueño?
• ¿Qué registros son privados, compartidos, archivados o públicos?
• ¿Qué estados existen y qué significa cada uno?
• ¿Qué datos nunca deberían borrarse sin backup?

Para muchos MVPs, un modelo simple alcanza. Pero tiene que ser intencional. Si la IA creó cinco tablas parecidas porque cada prompt agregó una funcionalidad nueva, frená y simplificá antes de que el uso real vuelva dolorosa la limpieza.

También revisá backups y migraciones. Si no podés explicar cómo restaurar la base después de un mal deploy, un borrado accidental o un error de plataforma, todavía no estás listo para tratar la app como producción.

Receta rápida: mapa de ownership de datos

Armá una tabla chica con cuatro columnas:

Dato	Dueño	¿Quién puede leerlo?	¿Quién puede cambiarlo?
Perfil de usuario	Usuario	Usuario, admin	Usuario, admin
Suscripción	Cuenta/workspace	Owner, admin	Webhook de pago, admin
Proyecto/cliente	Workspace	Miembros del workspace	Owner, editor

Si no podés completar esto, probablemente el backend tampoco pueda hacerlo cumplir de forma consistente.

4. Pagos: un redirect no es una confirmación

Las integraciones de pago merecen su propio pilar porque conectan ingresos, acceso de usuarios, soporte, analytics y comportamiento del backend.

Si usás Stripe, PayPal, Mercado Pago, Lemon Squeezy, Paddle u otro proveedor, no trates un redirect exitoso como prueba de que el pago está completo. Un redirect solo te dice que el usuario volvió a tu app. No prueba de forma confiable que el proveedor capturó el pago, que la suscripción está activa o que el evento quedó registrado correctamente.

Usá webhooks para confirmar pagos.

Un flujo seguro normalmente necesita que el backend reciba eventos del proveedor y actualice tu estado interno desde esos eventos. Por ejemplo:

• pago completado
• pago fallido
• pago pendiente
• suscripción creada
• suscripción renovada
• suscripción cancelada
• factura fallida
• reembolso emitido
• disputa abierta

Después tu app tiene que traducir esos eventos a estado de producto:

• usuario registrado pero no pago
• usuario pago pero onboarding incompleto
• usuario suscripto y activo
• usuario con pago pendiente
• usuario con suscripción vencida o en deuda
• usuario reembolsado o cancelado
• usuario que debería perder acceso después de un período de gracia

Acá es donde los flujos de pago mal vibe-codeados crean bugs caros. Podés terminar con usuarios registrados sin registro de pago, usuarios pagos sin acceso, usuarios gratis con acceso pago, pagos fallidos que desbloquean funcionalidades o eventos de revenue perdidos que rompen reportes.

Probá más que el camino feliz:

• checkout exitoso
• tarjeta o medio de pago fallido
• pago demorado o pendiente
• usuario cierra el navegador antes de volver a la app
• webhook llega antes que el redirect
• redirect llega antes que el webhook
• webhook duplicado
• reembolso
• chargeback o disputa
• cancelación de suscripción
• upgrade o downgrade de plan

Dos reglas importan mucho:

1. Verificá las firmas de los webhooks. No confíes en requests HTTP aleatorios que dicen ser eventos de pago.
2. Hacé que la activación sea idempotente. Si el mismo evento de pago llega dos veces, el backend no debería duplicar accesos, crear registros repetidos ni corromper el estado de la suscripción.

Si los pagos afectan el acceso, tu producto necesita una fuente de verdad clara para los permisos comerciales: qué puede hacer el usuario ahora mismo y por qué.

Receta rápida: flujo de confirmación de pagos

1. Creá el usuario como registered, no como paid.
2. Enviá al usuario al checkout.
3. Esperá un webhook verificado del proveedor de pagos.
4. Guardá el ID del evento del proveedor y el ID del pago o suscripción.
5. Actualizá el estado interno de acceso una sola vez, incluso si el evento llega dos veces.
6. Hacé que la UI lea el acceso desde tu estado interno, no desde la URL de redirect.

Esto evita el bug clásico: el usuario existe en tu app, pero el backend no sabe si pagó, falló, canceló, pidió reembolso o todavía está pendiente.

5. Testing: probá que sobreviva más que la demo

Las apps vibe-codeadas suelen pasar la demo porque la demo sigue exactamente el camino que se usó mientras se prompteaba. Los usuarios reales no.

Testing no tiene que arrancar como un departamento enorme de QA. Empezá con una checklist de lanzamiento que pruebe los flujos críticos:

• registrarse
• iniciar sesión
• cerrar sesión
• recuperar contraseña
• crear el objeto principal del negocio
• invitar a un compañero si existen equipos
• pagar o suscribirse si hay pagos
• acceder a funcionalidades pagas
• cancelar o hacer downgrade
• enviar el formulario más importante
• recibir el email más importante
• ver un error útil cuando algo falla

Para cada flujo crítico, probá tres versiones:

1. Camino feliz: todo funciona.
2. Falla de permisos: el usuario incorrecto intenta hacer la acción.
3. Flujo interrumpido: el usuario refresca, cierra la pestaña, reintenta o vuelve más tarde.

Si usás Claude Code, Codex, Cursor u otro agente de código, pedile tests antes de pedirle cambios grandes de comportamiento. Los tests le dan límites al agente. Sin tests, puede arreglar una pantalla y romper otra sin darse cuenta.

Receta rápida: primera suite de tests

Pedile a tu agente:

Identificá los cinco flujos de producto que más daño causarían a usuarios o revenue si se rompen. Escribí tests para esos flujos antes de cambiar código de implementación. Incluí un caso de permisos y un caso de flujo interrumpido para cada uno.

No arranques con 200 tests. Empezá por los flujos que te harían perder confianza, plata o datos.

6. GitHub: no dejes que la plataforma sea la única copia del producto

Si tu producto vive solo dentro de Lovable, Base44, Replit u otra plataforma, quizás te estás moviendo rápido, pero todavía no controlás del todo el producto.

Subí el proyecto a GitHub lo antes posible.

Un repo básico debería incluir:

• código fuente
• README con instrucciones de setup
• lista de variables de entorno sin valores secretos
• notas sobre stack y proveedores
• historial claro de commits
• issues o tareas para gaps conocidos
• branches o pull requests para cambios riesgosos

GitHub no es solo para developers. Te da ownership, historia, opciones de rollback y una forma de que futuros partners técnicos entiendan qué cambió y por qué.

El hábito es simple: antes de una sesión grande de prompts, commit. Después de un cambio significativo, commit. Antes de dejar que un agente de IA refactorice, commit. Si el resultado sale mal, podés volver atrás.

Receta rápida: README mínimo

Tu README debería responder:

• ¿Qué hace este producto?
• ¿Cómo se corre localmente?
• ¿De qué servicios depende?
• ¿Qué variables de entorno necesita?
• ¿Cómo funcionan auth, pagos y acceso a base de datos a alto nivel?
• ¿Qué está incompleto o se sabe riesgoso?

Un futuro developer no debería tener que hacer arqueología de prompts para entender el producto.

7. Deploy y ambientes: separá experimentos de producción

Uno de los patrones más peligrosos del desarrollo asistido por IA es editar producción directamente. Se siente rápido hasta que un prompt rompe la app que usuarios reales están usando.

Como mínimo, separá:

• ambiente local o preview para experimentar
• staging para probar
• producción para usuarios

Cada ambiente debería tener sus propias variables, claves de proveedores, base de datos, endpoints de webhook y modo de pagos. Stripe en test mode no debería tocar permisos de producción. Eventos sandbox de PayPal no deberían actualizar usuarios reales. Una base de staging no debería mandar emails a clientes reales salvo que lo hayas decidido explícitamente.

También definí cómo volvés atrás. Si un deploy rompe autenticación, acceso por pago o creación de datos core, ¿cuál es la forma segura más rápida de restaurar la versión anterior?

Receta rápida: frontera de producción

Antes de lanzar, dejá escrito:

• URL de producción
• base de datos de producción
• modo de pagos de producción
• endpoint de webhooks de producción
• comando o plataforma de deploy
• proceso de rollback
• quién tiene acceso admin

Si staging y producción comparten las mismas claves o la misma base por accidente, corregilo antes de que lleguen usuarios.

8. Observabilidad: enterate cuando algo se rompe

Si un usuario dice "pagué pero no puedo entrar a mi cuenta", necesitás más que vibras para debuggear.

Antes de lanzar, asegurate de poder ver:

• errores de la app
• requests de API fallidos
• eventos de webhooks de pago
• registros de usuarios
• cambios de suscripción o permisos
• envíos de formularios
• eventos importantes de conversión
• historial de deploys

No hace falta que sea complejo. Empezá con logs, analytics y un grupo chico de eventos de producto. Lo importante es que cada workflow crítico deje una huella.

Para pagos, registrá el ID del evento del proveedor, ID interno del usuario, cuenta o workspace, estado del pago y cambio de permisos. Así, cuando algo falla, podés reconstruir qué pasó.

Receta rápida: rastro para soporte

Para cada evento crítico, guardá suficiente contexto para responder:

• ¿Quién lo hizo?
• ¿Qué pasó?
• ¿Cuándo pasó?
• ¿Qué evento del proveedor o request de API lo disparó?
• ¿Qué cambió en el acceso o los datos del usuario?

Esa es la diferencia entre resolver un problema de soporte en diez minutos y adivinar durante dos días.

9. Si usás Claude Code o Codex, tratá al agente como un equipo junior muy rápido

Claude Code, Codex, Cursor y herramientas similares pueden ser muy útiles cuando el proyecto tiene estructura. Se vuelven riesgosas cuando el repo está desordenado, el prompt es vago y no hay tests.

Usá este flujo:

• Empezá desde un estado limpio de Git.
• Explicá el objetivo y los criterios de aceptación.
• Pedile al agente que inspeccione antes de editar.
• Mantené los cambios chicos.
• Pedile tests o actualización de tests existentes.
• Revisá el diff antes de aceptar.
• Corré la app y la suite de tests.
• Commiteá solo cuando el resultado sea entendible.

No le pidas a un agente que "arregle toda la app" en una sola pasada. Pedile un subsistema, un bug, un flujo o un refactor por vez.

Y tené especial cuidado con auth, migraciones de base de datos, lógica de pagos, permisos y configuración de producción. Esos no son buenos lugares para confiar a ciegas.

Prompts útiles para agentes de código

• "Inspeccioná este codebase primero. No edites todavía. Decime cómo están estructurados auth, pagos, acceso a base de datos y deploy."
• "Encontrá lugares donde el frontend parece aplicar una regla que el backend no aplica."
• "Antes de cambiar esta funcionalidad, escribí o actualizá tests para el comportamiento esperado actual."
• "Revisá este diff como si estuvieras buscando bugs de seguridad, pérdida de datos, pagos y permisos."
• "Hacé el cambio seguro más chico posible. Si hace falta un refactor más grande, proponé un plan antes de editar."

El mejor workflow con agentes no es magia. Es cambios chicos, criterios claros, tests y revisión.

La regla práctica antes de lanzar

Si la app solo te ayuda a validar un concepto, movete rápido. Usá IA fuerte. Construí la versión clickeable. Aprendé de usuarios.

Pero si la app tiene cualquiera de estas cosas, bajá un cambio y auditá:

• usuarios reales
• datos privados
• pagos
• suscripciones
• acceso admin
• dashboards para clientes
• base de datos en producción
• integraciones de terceros
• demos a inversores o clientes que prometen confiabilidad

La pregunta no es si el producto fue construido con IA. La pregunta es si alguien revisó las partes que las herramientas de IA suelen saltearse: autenticación, seguridad, ownership de datos, confirmación de pagos, tests, deploy, observabilidad y mantenibilidad.

El objetivo no es dejar de vibe-codear. El objetivo es que tu producto no dependa de suerte, prompts viejos, estados invisibles y supuestos que nadie revisó.

---

Lecturas recomendadas

• Guía de Stripe sobre fulfillment y webhooks en Checkout
• Eventos de webhook para Checkout en PayPal
• Integración y verificación de webhooks en PayPal
• OWASP Authentication Cheat Sheet
• OWASP Session Management Cheat Sheet