¿Cuánto cuesta dejar lista para producción una app vibe-coded?

Lanzaste un producto con Lovable, Cursor o Claude Code en un fin de semana, y ahora alguien quiere pagar por él. La siguiente pregunta es la que nadie metió en el precio del prototipo: ¿cuánto cuesta hacerlo seguro para operar? Este post va de dinero y tiempo, no de si el vibe-coding fue un error. No lo fue. Te trajo hasta aquí. La factura por las partes que el modelo se saltó solo está llegando ahora.

Los números aquí son rangos del historial de proyectos de Wavect con código generado por IA, planteados como típicos, no como un presupuesto. Quien te dé una cifra precisa para una base de código que nunca ha visto está adivinando, y la estimación siempre es optimista. Definimos el alcance tras un primer vistazo.

¿Por qué pagas en realidad?

No pagas por reescribir software que funciona. Pagas por el trabajo que el prompt nunca pidió: la autorización que el modelo dejó en el frontend, los secretos que puso en línea para que el ejemplo corriera, las consultas que están bien con diez filas y son fatales con cien mil. Nada de eso se ve en una demo. Todo se ve el día del lanzamiento. El coste de una pasada para dejarlo listo para producción es el coste de encontrar y cerrar esa brecha antes de que un usuario la encuentre por ti.

El trabajo se divide en dos fases, y se cotizan distinto. La primera es la auditoría: una lectura estructurada para encontrar lo que se esconde. La segunda es el hardening: arreglar lo que la lectura saca a la luz. La mayor parte del tiempo y el dinero está en la segunda, pero la primera te dice cómo de grande es la segunda.

¿Cuánto cuesta la auditoría en sí?

Una auditoría es la parte barata, y es la parte que te compra certeza sobre todo lo demás. Va de unos días a cerca de una semana de trabajo enfocado, según cómo de grande sea la base de código y cuánto dinero real o datos sensibles toque. Una herramienta interna de solo lectura está en el extremo corto. Un producto que cobra pagos y guarda datos personales está en el extremo largo, porque esas son exactamente las partes que necesitan la lectura más fina. El entregable es un informe de hallazgos ordenado por gravedad y una estimación honesta del hardening que sigue. Lo que una auditoría encuentra de verdad lo cuentas en nuestro artículo sobre la auditoría de software vibe-coded.

¿Cuánto cuesta el hardening?

Aquí cae el gasto real, y escala con lo que la auditoría encontró. La forma honesta de hablar de ello son rangos, porque dos productos con la misma lista de funciones pueden necesitar trabajo muy distinto según lo que el modelo dejó atrás.

Tómalos como direccionales. La varianza dentro de cada fila la determinan dos cosas: cuánto dinero real o datos sensibles toca el producto, y cuán lejos corrió la IA sin que nadie la guiara. Un prototipo de fin de semana que maneja pagos y datos personales necesita más que un fin de semana de QA.

¿A dónde va el tiempo en realidad?

La gente espera que la factura la domine escribir código nuevo. No es así. En una pasada típica de hardening sobre software vibe-coded, el reparto aproximado es este.

• Leer y reproducir, 20 a 30 %. Entender qué construyó el modelo y reproducir los fallos antes de tocar nada. No puedes arreglar lo que no has confirmado que está roto.
• Autorización y acceso a datos, 25 a 35 %. Casi siempre la mayor línea individual. Mover las comprobaciones de acceso del frontend al servidor y aislar tenants en la capa de base de datos es trabajo lento y cuidadoso, porque toca cada endpoint.
• Rutas de fallo, validación, secretos, 15 a 25 %. El medio poco glamuroso. Manejo de errores en cada llamada externa, límites de entrada y sacar las claves del cliente y rotarlas.
• Tests y una suite de regresión, 15 a 20 %. Escribir los tests que el prototipo nunca tuvo, para que el próximo cambio no deshaga este.

El patrón que sorprende a los fundadores: el trabajo de funciones nuevas suele ser la porción más pequeña. La parte cara es la infraestructura invisible que una demo nunca ejercita.

"El coste de hacer seguro el software vibe-coded no es el coste de reescribirlo. Es el coste del trabajo que el prompt nunca pidió, y ese trabajo no desapareció porque un modelo escribiera el primer borrador."

¿Qué encuentra normalmente la auditoría?

Los hallazgos se agrupan, lo que los hace estimables. A lo largo de builds vibe-coded, los mismos puntos aparecen una y otra vez: un login que funciona sin comprobación en el servidor que impida al usuario A leer los datos del usuario B, secretos en el bundle del cliente, sin manejo de errores fuera del camino feliz, consultas que colapsan con carga y ningún test. El desglose completo de lo que se rompe y cómo lo ordenamos por gravedad está en nuestro post QA para código generado por IA, y el trabajo de migración paso a paso en del prototipo en Lovable y Cursor a producción.

¿Cuánto cuesta no hacerlo?

Esta es la comparación que importa. Una pasada de hardening es un coste conocido, acotado y único. La alternativa es un coste desconocido pagado en el peor momento posible. Una clave de pagos filtrada no es una línea de presupuesto, es un incidente. Una comprobación de autorización ausente no es un bug, es una fuga de datos con secuelas regulatorias y de reputación. El planteamiento honesto no es "una auditoría cuesta dinero", es "una auditoría es un seguro barato contra encontrar las mismas brechas por las malas, después del incidente en vez de antes".

¿Cuándo reconstruir es más barato que hacer hardening?

A veces la lectura muestra que el núcleo en sí está mal: un modelo de datos que no puede sostener lo que el producto necesita, o el mismo patrón roto copiado por toda la base de código, de modo que cada arreglo hay que hacerlo cien veces. Cuando pasa eso, reconstruir el núcleo es más barato que parchearlo para siempre, y lo diremos en la primera llamada en vez de cobrarte por parchear unos cimientos que hay que volver a verter. Parchear unos cimientos que hay que volver a verter es la forma más cara de ahorrar dinero.

¿Cómo cotiza Wavect este trabajo?

Usamos precio fijo ágil con precio cerrado una vez que la auditoría ha quitado las mayores incógnitas. La auditoría se acota pequeña y ajustada. El hardening se acota a partir de lo que la auditoría encontró, con bloqueantes, altos y limpieza separados, de modo que tú decides qué financias y cuándo. Nunca se te pide firmar una cifra cerrada por trabajo que nadie ha mirado todavía. Esta es la puerta de entrada de nuestro servicio de aseguramiento de calidad de software.