De prototipo con IA a producción: lo que siempre falta cuando la demo ya funciona

Entre una demo que funciona y un producto en producción hay siete bloques de trabajo que la IA no genera sola: autenticación y permisos, datos y copias, pagos y accesos, límites y abuso, observabilidad, costes y propiedad del código. En una app que toca dinero o datos personales, ese trabajo suele ser mayor que el de construir la demo.

Y no es una mala noticia. Es la noticia que conviene tener antes de firmar el presupuesto, no después.

Esta pieza es la continuación práctica de qué es el vibe coding. Allí explico dónde está el límite; aquí, qué hay exactamente al otro lado.

¿Por qué una demo generada con IA parece más terminada de lo que está?

Porque lo que se ve funciona. El diseño es correcto, la navegación responde, los formularios guardan, hay datos en las tablas. Todas las señales que un ser humano usa para juzgar si algo está acabado están en verde.

Lo que falta es, por definición, invisible: lo que pasa cuando entra otro usuario, cuando el pago falla, cuando alguien manda mil peticiones seguidas, cuando el servicio de terceros devuelve un error, cuando hay que averiguar qué ocurrió hace tres días.

Osea: la demo demuestra que el camino feliz existe. Producción es todo lo demás.

Entender es el verdadero atajo, y aquí se nota: el equipo que sabe qué le falta negocia bien con su cliente. El que no lo sabe promete una fecha y se come el retraso.

Los siete bloques que siempre faltan

1. Autenticación y permisos de verdad

Una demo tiene una pantalla de login. Un producto tiene un modelo de permisos.

La diferencia es dónde se decide quién puede hacer qué. Si la comprobación está en el navegador (“si el usuario no es admin, no muestro el botón”), no es seguridad: es decoración. Cualquiera puede llamar a la API igualmente. La verificación tiene que ocurrir en el servidor o en la base de datos, en cada petición.

Esto es la categoría número uno del OWASP Top 10:2025, control de acceso roto (consultado en septiembre de 2026). Es la primera por frecuencia y es exactamente el punto ciego de cualquier prototipo.

Qué hay que tener resuelto:

• Roles definidos con nombres del negocio, no genéricos: quién es cliente, quién es gestor de cuenta, quién es administrador.
• Cada endpoint y cada tabla con una regla explícita de quién accede.
• Reglas a nivel de fila cuando varios clientes comparten base de datos: el cliente A no puede ver los registros del cliente B ni cambiando un identificador en la URL.
• Sesiones que caducan, cierre de sesión que invalida de verdad, y recuperación de contraseña que no sea un agujero (categoría A07:2025, fallos de autenticación).

Si la app usa Supabase, esto pasa por Row Level Security, y la documentación oficial es tajante: “una tabla en un esquema expuesto sin RLS es legible y escribible por cualquier rol que tenga permiso sobre ella” (consultado en septiembre de 2026). No es opcional.

2. Datos, copias y recuperación

Pregunta incómoda: si mañana se borra la base de datos por error, ¿cuánto se pierde y cuánto se tarda en volver?

Si la respuesta es “no lo sé”, no hay copias de seguridad; hay una esperanza.

Lo mínimo para producción:

• Copias automáticas con una frecuencia que encaje con cuánto dato se puede permitir perder.
• Una restauración probada al menos una vez. Una copia que nunca se ha restaurado no es una copia, es un fichero.
• Un esquema de datos con claves únicas y restricciones, para que los duplicados no entren.
• Un plan de migraciones: cómo se cambia el esquema sin romper lo que ya hay dentro.
• Saber dónde están alojados los datos y qué se guarda de cada persona, porque alguien te lo va a preguntar por escrito.

3. Pagos y accesos

El bloque donde los errores cuestan dinero literal en vez de tiempo.

Cobrar bien no es poner un botón de Stripe. Es que el estado del pago y el estado del acceso estén sincronizados siempre, en los dos sentidos:

• Webhooks verificados y idempotentes. El proveedor puede reenviar el mismo evento; si tu código lo procesa dos veces, das dos accesos o cobras dos veces. La documentación de webhooks de Stripe explica la verificación de firma y el reintento de eventos (consultado en septiembre de 2026).
• El precio se calcula en el servidor. Nunca en el navegador, nunca confiando en un valor que llega del cliente.
• Impagos y cancelaciones revocan el acceso sin que nadie tenga que acordarse. Este flujo concreto, con sus estados intermedios, lo desgloso en pagos fallidos en Stripe y control de accesos.
• Reembolsos y cambios de plan contemplados, no improvisados el día que pasan.

4. Límites y abuso

Una demo la usan cinco personas amables. Producción la usa internet.

• Límite de peticiones por usuario y por IP en los endpoints caros o sensibles.
• Validación de todo lo que entra, en el servidor. Es la raíz de la categoría A05:2025, inyección.
• Tamaño máximo de subidas y tipos de fichero permitidos.
• Protección en formularios públicos, o el primer bot te llena la base de datos de basura.
• Si hay llamadas a modelos de IA dentro del producto: tope de gasto por usuario. Sin eso, un abuso puntual se convierte en una factura.

5. Observabilidad

El bloque que nadie presupuesta y todos echan de menos.

• Logs de lo que pasa en los flujos críticos: quién hizo qué y cuándo.
• Alertas cuando algo falla, que lleguen a un canal que alguien mira. Un error que nadie ve es un error que sigue ocurriendo.
• Captura de errores en cliente y servidor, agrupada, con contexto suficiente para reproducir.
• Métricas mínimas: peticiones, latencia, errores. No hace falta un panel bonito; hace falta poder responder “¿está bien ahora?” en diez segundos.

El OWASP Top 10:2025 incluye los fallos de registro y alerta como categoría propia. Y en la práctica, es la diferencia entre enterarte por tu monitorización o por un correo del cliente enfadado.

Este es el mismo problema que describo en automatizaciones que fallan en silencio, pero aplicado a una aplicación en vez de a un flujo.

6. Costes previsibles

Las plataformas de prototipado cobran por uso, y el uso durante el desarrollo no se parece al uso en producción.

Bolt, por ejemplo, documenta que el consumo de tokens crece con el tamaño del proyecto: “la mayor parte de tu uso de tokens viene de que Bolt lee, entiende y sincroniza los ficheros de tu proyecto, así que los proyectos más grandes usan más tokens por mensaje” (soporte de Bolt, consultado en septiembre de 2026). Y Figma limita Make a asientos completos de planes de pago (centro de ayuda de Figma, consultado en septiembre de 2026).

Antes de lanzar hay que tener una cuenta clara de: hosting, base de datos, envío de correo, pasarela de pago, modelos de IA si los hay, y el coste de la propia herramienta de construcción si se sigue usando para mantener. Un producto que cuesta más de operar que lo que ingresa no es un producto, es un hobby caro.

7. Propiedad del código y del stack

La pregunta que hay que hacer el primer día: cuando esto esté terminado, ¿a nombre de quién está todo?

• Repositorio de código, con su historial.
• Base de datos y sus copias.
• Dominio y DNS.
• Cuentas de los servicios de terceros y sus claves.
• Si el prototipo vive dentro de una plataforma cerrada, cómo se sale de ahí y qué se pierde por el camino.

Esto no es desconfianza, es higiene. Y para una agencia es especialmente relevante: si el cliente final tiene que entrar en la cuenta de la agencia para ver su propia base de datos, eso es una conversación pendiente que va a llegar en el peor momento.

Checklist de puesta en producción

Imprimible, para ir marcando. Si no puedes marcar una casilla, eso no es una tarea pendiente: es un riesgo abierto.

Permisos

• Todas las comprobaciones de permisos ocurren en el servidor o en la base de datos.
• Un usuario no puede acceder a datos de otro cambiando un identificador en la URL.
• Los roles están definidos y documentados en términos del negocio.
• Las sesiones caducan y el cierre de sesión invalida el token.

Secretos y configuración

• Ninguna clave de API ni credencial aparece en el código del navegador.
• Las variables de entorno de producción son distintas a las de desarrollo.
• Los mensajes de error no exponen trazas internas al usuario final.
• Las dependencias están actualizadas y sin vulnerabilidades conocidas.

Datos

• Hay copias de seguridad automáticas.
• Se ha restaurado una copia al menos una vez, de verdad.
• El esquema tiene claves únicas y restricciones.
• Está documentado qué datos personales se guardan y dónde.

Pagos y accesos

• Los webhooks verifican la firma del proveedor.
• Procesar el mismo evento dos veces no duplica nada.
• Los importes se calculan en el servidor.
• Un impago o una cancelación revocan el acceso automáticamente.

Límites

• Hay límite de peticiones en los endpoints sensibles.
• Toda entrada se valida en el servidor.
• Las subidas tienen límite de tamaño y de tipo.
• Hay tope de gasto en las llamadas a modelos de IA, si las hay.

Observabilidad

• Los flujos de dinero y accesos dejan registro.
• Las alertas llegan a un canal que alguien mira.
• Los errores se capturan con contexto suficiente para reproducirlos.
• Alguien tiene asignado el papel de mirar esto.

Costes y propiedad

• Hay una estimación mensual de coste de operación.
• Repositorio, base de datos, dominio y cuentas están a nombre de quien corresponde.
• Existe un plan de mantenimiento con responsable y frecuencia.
• Está escrito qué pasa si mañana cambia el proveedor técnico.

¿Se reescribe o se aprovecha?

Casi siempre se aprovecha bastante más de lo que la gente teme.

La interfaz, el flujo de pantallas y buena parte de los componentes suelen ser perfectamente válidos: es donde estas herramientas son realmente buenas. Lo que hay que rehacer es la capa que decide cosas: acceso a datos, permisos, lógica de negocio y todo lo que toque dinero.

El orden que sigo:

1. Revisar el código existente y clasificar qué se queda, qué se refactoriza y qué se tira. Cómo hacer esa revisión está en revisar código generado por IA.
2. Mover la fuente de verdad a una base de datos con dueño, esquema y restricciones.
3. Reconstruir permisos en servidor, con pruebas que comprueben que un usuario no ve lo del otro.
4. Cerrar el circuito de pagos y accesos con webhooks idempotentes.
5. Instrumentar: logs, alertas, captura de errores.
6. Endurecer: límites, validación, secretos fuera del cliente.
7. Documentar y entregar: quién mantiene esto y cómo.

Es el mismo patrón de migración por piezas que describo al pasar de no-code a software a medida: nunca un apagón y encendido, siempre sustituir la pieza que más duele primero.

Cómo encaja esto en el presupuesto de una agencia

Una recomendación concreta, de las que ahorran discusiones: separad la propuesta en dos.

Fase 1 — Prototipo. Corta, barata, con IA, sin promesas de producción. Su entregable es una demo funcional y una decisión: seguimos o no.

Fase 2 — Producto. Con los siete bloques de arriba como alcance explícito. Si el cliente ve la lista, entiende por qué cuesta lo que cuesta. Si no la ve, solo compara el precio con el tiempo que tardasteis en enseñarle la demo, y siempre vais a parecer caros.

Y la parte técnica de la fase 2 no tiene por qué ser vuestra. Trabajar con un socio en white label os permite vender el proyecto completo manteniendo la relación con el cliente, sin contratar un perfil técnico a jornada completa para un proyecto puntual.

¿Tienes una demo y no sabes qué le falta?

Eso es literalmente el punto de partida con el que más trabajo: una app hecha con Lovable, Bolt, v0 o Figma Make que funciona, que el cliente ya ha visto, y que nadie se atreve a poner delante de usuarios reales.

Cuéntame qué has construido y te devuelvo la lista concreta de lo que falta, con prioridades y con lo que se aprovecha. Si después hay que construir la versión sólida, eso es software a medida; si lo que necesitáis es tener un equipo técnico detrás de forma continuada y en white label, es partner tecnológico.