Tu prototipo con IA funciona en la demo. Hazlo funcionar en producción.
La demo convence. Producción es otro deporte: usuarios reales, datos reales, atacantes reales. Pasar un prototipo de IA a producción consiste en auditar lo que generó la herramienta, conservar lo que vale y reconstruir lo que no aguanta: auth, datos, despliegues. Doomity lo hace con un Production Readiness Sprint de 5 días y alcance fijo. No tiramos tu trabajo: lo endurecemos.
Actualizado: julio de 2026
- 1 Día 1 Kickoff y accesos → Inventario de evidencias
- 2 Día 2 Revisión técnica → Hallazgos con pruebas
- 3 Día 3 Mapa de riesgos → Cada hallazgo clasificado
- 4 Día 4 Opciones A/B/C → Trade-offs sobre la mesa
- 5 Día 5 Sesión ejecutiva → Roadmap 30/60/90
¿Por qué tu app hecha con IA se rompe con usuarios reales?
Porque la herramienta optimizó que la demo funcione, no que el sistema resista. En los prototipos generados con IA que auditamos aparecen, casi siempre, los mismos 5 fallos:
- Auth de mentira. Hay pantalla de login, pero las rutas y la API aceptan peticiones de cualquiera que sepa dónde llamar.
- RLS abierta. La base de datos (Supabase, casi siempre) no tiene políticas por fila: un usuario puede leer los datos de todos.
- Secretos en el frontend. Claves de API y tokens empaquetados en el JavaScript que se descarga cualquier visitante.
- Sin rollback. Se despliega directo a producción; si el cambio rompe algo, no hay vuelta atrás.
- Sin tests. Cada funcionalidad nueva puede romper en silencio la anterior, y nadie se entera hasta que un cliente avisa.
Ninguno de los 5 se ve en la demo. Todos salen caros con el segundo usuario. Puedes comprobar cuántos te afectan en 3 minutos con nuestro diagnóstico de producción. Y si tu app ya está lanzada y rompiéndose, eso ya no es endurecer: mira el rescate de proyectos de software.
¿Es seguro el código que genera la inteligencia artificial?
A medias, y la diferencia importa. El informe de Veracode 2025 analizó código generado por más de cien modelos de IA: en torno al 45% de las tareas introdujo vulnerabilidades conocidas. En cross-site scripting el suspenso llegó al 86% de los casos; en log injection, al 88%.
No es que la IA programe mal. Es que escribe el código más corto que pasa la prueba, y la seguridad es justo lo que no se prueba en una demo. Por eso el Sprint empieza auditando lo generado, no añadiendo funcionalidades. Primero se cierra la puerta; luego se amuebla la casa.
¿Vais a tirar mi prototipo y reescribirlo todo desde cero?
Casi nunca, y quien te lo proponga el primer día vende su comodidad. Tu prototipo ya resolvió lo más caro: validar qué quieren tus usuarios. La interfaz, los flujos y las reglas de negocio son trabajo hecho. Lo que se decide con la auditoría es la capa invisible:
| Capa | Qué hacemos con ella |
|---|---|
| Interfaz y flujo de pantallas | Se conserva. Es lo que tus usuarios ya validaron. |
| Reglas y validación de negocio | Se conservan y se cubren con tests. |
| Auth y permisos | Se reconstruyen casi siempre. Es el fallo número 1. |
| Modelo de datos y accesos | Se audita; se corrige lo que exponga datos. |
| Despliegue, CI y rollback | Se montan de cero. Los prototipos no los traen. |
Nuestra postura, discutible pero honesta: la mayoría de prototipos de vibe coding no merecen ir a producción tal cual. Merecen ir después de esta criba, conservando lo validado.
¿Cómo funciona el Production Readiness Sprint de 5 días?
Es un sprint de alcance fijo: 5 días, mismos pasos, entregables garantizados. Garantizamos proceso y entregables, nunca resultados: nadie honesto puede prometerte cero incidentes.
- Audit del código generado. Leemos el repositorio completo: auth, datos, secretos, dependencias, despliegue.
- Mapa de riesgos. Cada hallazgo, clasificado por gravedad: qué expone datos, qué tumba el servicio, qué solo es feo.
- Plan de endurecimiento. Qué se conserva, qué se reconstruye y en qué orden, con esfuerzo estimado por bloque.
- Endurecimiento de lo crítico. Cerramos dentro del propio Sprint los riesgos que bloquean el lanzamiento, con cambios pequeños y reversibles.
Sales con un plan que te sirve aunque lo ejecute otro equipo. Cómo trabajamos, con qué stack y con qué controles está publicado en nuestro método.
¿Con qué herramientas de vibe coding puede trabajar Doomity?
Lovable, Bolt, Replit, Cursor, Base44, v0 y, en general, cualquier prototipo con el código exportable a un repositorio. Cada herramienta tiene sus vicios y los conocemos: los prototipos de Lovable y Bolt suelen llegar con Supabase y las políticas RLS sin definir; los de v0, con lógica de servidor metida en componentes de cliente; los de Replit, con la app y los datos conviviendo en el mismo entorno de desarrollo.
Lo que auditamos no es la herramienta: es el código que dejó. Si puedes darnos acceso al repositorio, o exportarlo, podemos trabajar. Y si la herramienta no exporta el código, esa es ya tu primera bandera roja como propietario del producto.
¿Qué pasa con los datos personales que ya metiste en el prototipo?
Probablemente ya tienes un problema de RGPD y nadie te lo ha dicho. Si tus primeros usuarios de prueba metieron correos, nombres o pagos en el prototipo, eres responsable del tratamiento desde ese día, no desde el lanzamiento oficial. Muchos prototipos guardan esos datos en regiones fuera de la UE o los envían a APIs de IA sin contrato de encargado de tratamiento.
En el Sprint lo tratamos como un riesgo más del mapa: inventario de qué datos personales existen, dónde se alojan, qué proveedores los ven y qué hay que firmar o mover antes de abrir el registro al público. Sin alarmismo y sin humo legal: una lista de acciones concretas, priorizada.
¿Por qué Doomity sabe endurecer código generado por IA?
Porque leer código ajeno con prisa es nuestro oficio. Doomity LLC es una firma de desarrollo de software especializada en software a medida, modernización de sistemas legacy, paso de prototipos de IA a producción, rescate de proyectos de software y due diligence tecnológica, que trabaja con clientes de EE. UU., Reino Unido, España y Portugal.
Detrás hay equipos que han construido para Holcim, Canon España e Indra, con los mismos controles que exige ese tipo de cliente: revisión por pares, CI, despliegues reversibles. Aplicamos esa vara de medir a tu prototipo, por escrito y con nombre. Todo empieza con una llamada de 25–30 minutos con un ingeniero, no con un comercial.
FAQ
Para Doomity, una app está lista para producción cuando cumple una lista concreta, no un sentimiento: auth verificada en cada ruta y endpoint, permisos a nivel de dato, secretos fuera del código del cliente, copias de seguridad restauradas al menos una vez, despliegue con rollback probado, tests sobre los flujos que dan de comer al negocio y monitorización que avisa antes que tus clientes. El mapa de riesgos del Sprint puntúa tu prototipo contra esa lista, punto por punto. Lo que no se mide contra una lista se discute con opiniones, y las opiniones no paran una brecha.
Casi nunca. La interfaz, los flujos de pantalla y las reglas de negocio de tu prototipo son trabajo validado por usuarios reales, y se conservan. Lo que suele reconstruirse es la capa invisible: auth, permisos sobre datos y el circuito de despliegue, porque las herramientas de vibe coding no los generan a nivel de producción. La reescritura total solo se plantea cuando la auditoría la justifica con datos, y en ese caso te lo diremos con el coste de cada alternativa delante. Decidir a ciegas entre conservar y reescribir es la forma más cara de equivocarse.
No por defecto. El informe GenAI Code Security de Veracode (2025) midió código generado por más de cien modelos: alrededor del 45% de las tareas introdujo vulnerabilidades conocidas, con suspensos del 86% en cross-site scripting y del 88% en log injection. Eso no convierte tu prototipo en basura: convierte la auditoría en obligatoria antes de exponerlo a usuarios reales. La buena noticia es que estos fallos son conocidos, localizables y corregibles en días, no en meses, si se buscan de forma sistemática en lugar de esperar a que los encuentre otro.
El Sprint dura 5 días fijos: auditoría, mapa de riesgos, plan de endurecimiento y cierre de los riesgos que bloquean el lanzamiento. Cuánto trabajo queda después depende de lo que aparezca en la auditoría, y no vamos a inventarte un plazo sin haber leído tu código. Lo que sí garantizamos es que sales del Sprint con fechas: el plan incluye el esfuerzo estimado de cada bloque pendiente, ordenado por riesgo, para que decidas qué endurecer antes de lanzar y qué puede esperar a la versión siguiente.
Lovable, Bolt, Replit, Cursor, Base44, v0 y cualquier otra herramienta cuyo resultado puedas exportar a un repositorio de código. También prototipos escritos a mano con ayuda de Copilot o Claude. La herramienta importa menos que su huella: cada una deja patrones de fallo típicos que ya conocemos, y eso acelera la auditoría. El único caso que no podemos endurecer es una plataforma cerrada que no permite sacar el código; ahí el trabajo empieza por migrarlo a un stack que sí controles tú.
Dos planos. Tus datos con nosotros: firmamos acuerdo de confidencialidad antes de ver el repositorio, accedemos con cuentas nominales y los accesos se revocan al terminar. Los datos de tus usuarios en el prototipo: el Sprint incluye un inventario de qué datos personales existen, en qué región se alojan y qué proveedores (incluidas APIs de IA) los reciben, con la lista de contratos de encargado de tratamiento que faltan por firmar. Si ya hay datos reales de usuarios en el prototipo, el RGPD ya te aplica; mejor saberlo antes de abrir el registro al público.
¿Tu app creada con IA aguanta producción? Autodiagnóstico en 10 preguntas
Diez preguntas, dos minutos. Recibes una puntuación, una banda de riesgo y los tres arreglos que hacer antes de que lleguen usuarios reales — antes de dejarnos tu email.
Pregunta 1 de 10
¿Dónde enviamos tu resultado?
Email de trabajo. Tu puntuación y acciones aparecen aquí mismo; sin newsletter.
No hemos podido procesar tus respuestas. Revisa tu conexión e inténtalo de nuevo.
Tu prototipo ya hizo lo difícil: demostrar que la idea interesa. Lo que queda es evitar que el primer mes con usuarios reales lo desmonte. Con cerca de la mitad del código generado por IA introduciendo vulnerabilidades, lanzar sin auditar no es rapidez: es una apuesta con los datos de tus clientes. En 5 días puedes saber exactamente qué le falta a tu app.