Casi nunca. Una aplicación construida con IA suele estar al 80 % de lo que se ve —las pantallas, los flujos, buena parte de los datos— y al 20 % de lo que la sostiene: permisos reales, migración de tus datos actuales, copias de seguridad, trazabilidad y cumplimiento legal. La buena noticia es que eso no significa empezar de cero: significa terminar lo que falta. En Dediez Software llevamos más de 15 años haciendo exactamente esa segunda parte.
Si has llegado hasta aquí es probable que te reconozcas en esta escena: pediste presupuesto para una herramienta interna, te pareció desproporcionado o sistemas nunca encontró el hueco, y un fin de semana decidiste probar tú mismo con Claude Code, Cursor, Lovable o ChatGPT. Y funcionó. Funcionó de verdad.
Lo primero que hay que decir es esto: no has perdido el tiempo, y no has tirado el dinero. Has hecho algo que la mayoría de tus homólogos ni siquiera intentaría. Lo que ocurre ahora es otra cosa, y tiene nombre.
Lo que has construido es un prototipo, y eso es una buena noticia
Un prototipo no es un producto a medias. Es una pieza con una función muy concreta: demostrar que la idea funciona antes de invertir en construirla bien. Y la tuya la ha cumplido.
Piénsalo desde el otro lado. En cualquier proyecto de software a medida, la fase cara y arriesgada no es programar: es averiguar qué necesita de verdad la empresa. Reuniones de toma de requisitos, documentos funcionales que nadie lee entero, malentendidos que aparecen el día de la entrega y un presupuesto inflado precisamente para cubrir toda esa incertidumbre.
Tú te has saltado esa fase entera. No has descrito lo que querías: lo has construido y lo has probado con tu propia gente. Sabes qué campos hacen falta, qué flujo usa el equipo de verdad y cuáles de tus ideas iniciales no servían para nada.
Consejo Dediez: Tu prototipo es el mejor documento funcional que existe de tu proyecto. Guárdalo, no lo escondas. Es el activo más valioso que vas a poner encima de la mesa el día que hables con un proveedor.
Eso tiene una consecuencia muy práctica: un proyecto que parte de un prototipo funcionando se presupuesta con mucho menos riesgo que uno que empieza en blanco. Y lo que baja el riesgo, baja el precio.
El 80 % que se ve y el 20 % que sostiene
La sensación más común entre quienes han construido algo con IA es la de estar "casi", y llevar semanas sin avanzar de ese casi. No es una impresión: es la estructura del problema.
Las herramientas de IA son extraordinariamente buenas en lo que tiene forma visible —una pantalla, un formulario, un listado, un informe— porque es lo que se les puede pedir con palabras y lo que se puede comprobar de un vistazo. Son mucho peores en todo lo que no se ve y nadie te sugiere pedir, sencillamente porque no sabes que existe hasta que te falla.
Este es el desglose que nos encontramos una y otra vez:
- Pantallas y flujos principales: entre el 70 % y el 90 %. Es lo que ves y por eso parece que está casi.
- Modelo de datos: entre el 50 % y el 70 %. Normalmente rescatable con retoques.
- Reglas de negocio: entre el 40 % y el 60 %, con los casos límite sin cubrir. Funciona con el caso normal y se rompe con la excepción.
- Autenticación y permisos por rol: entre el 10 % y el 30 %. Suele servir contigo delante, no con quince personas usando el sistema a la vez.
- Multiempresa o multiusuario concurrente: casi siempre sin resolver.
- Migración de los datos que ya tienes: cero. Y sin eso la aplicación no arranca de verdad.
- Copias de seguridad y recuperación: cero o casi. La pregunta incómoda es qué pasa mañana si alguien borra algo por error.
- Trazabilidad: cero. Quién cambió qué y cuándo, que es lo primero que te van a preguntar el día que haya un problema.
- RGPD y datos personales: cero. Consentimientos, derecho de supresión, encargado del tratamiento, dónde están alojados los datos.
- Rendimiento con volumen real: sin probar. Cuatro registros de prueba no son tus 40.000 líneas de histórico.
- Integraciones con lo que ya usa tu empresa: entre el 0 % y el 20 %.
- Alguien que responda cuando falle: cero. Hoy el departamento de informática de tu herramienta eres tú.
Míralo de nuevo con calma. Ninguno de esos puntos es un capricho técnico: todos son preguntas de negocio, y cada uno tiene una factura asociada el día que se ignora.
Las cinco señales de que ya no es un experimento
Mientras el prototipo lo usas tú, es un experimento y no pasa nada. El problema empieza cuando cruza una de estas líneas, casi siempre sin que nadie lo decida formalmente:
1. Lo usa alguien que no lo ha construido
En cuanto entra la segunda persona aparecen los permisos, los errores de uso, los datos mal introducidos y las preguntas que solo tú puedes responder. Tu agenda empieza a llenarse de interrupciones.
2. Ha habido un susto con los datos
Alguien borró algo, o se duplicó un registro, o desapareció un campo. Y descubriste que no hay copia, o que la hay pero nunca se ha probado restaurarla. Una copia que no se ha restaurado nunca no es una copia: es una suposición.
3. Has llegado al techo de lo que la IA te resuelve
El síntoma exacto es este: cada cambio que pides arregla una cosa y rompe otra. No es que la herramienta haya empeorado; es que el sistema ha crecido más de lo que cabe en una conversación, y ya nadie —ni tú ni la IA— tiene la foto completa.
4. Alguien de fuera lo ha mirado
Un asesor, un cliente grande, el responsable de IT del grupo. Y ha hecho preguntas que no sabes contestar: dónde están los datos, quién accede, qué pasa si te vas de la empresa.
5. Quieres facturar con ello o dárselo a tus clientes
En cuanto el sistema toca dinero o toca a terceros, el listón sube de golpe y ya no hay marcha atrás.
Consejo Dediez: Si has cruzado dos o más de estas cinco líneas, tu prototipo ya está en producción aunque nadie lo haya declarado. Y un sistema en producción sin copias, sin permisos y sin responsable es un riesgo de negocio, no un proyecto de informática.
Lo que no hay que hacer: empezar de cero
Cuando un directivo nos enseña por fin lo que ha construido, suele hacerlo con una disculpa por delante. Y espera que le digamos que hay que tirarlo.
Casi nunca es así, y decirlo sería además una mala recomendación profesional. Por experiencia, en un prototipo hecho con IA:
- Lo que suele sobrevivir: el modelo de datos, la estructura de la información y la experiencia de uso. Es decir, justo lo que costó descubrir.
- Lo que rara vez sobrevive: la capa de reglas de negocio y toda la infraestructura, que es lo que se construye rápido pero hay que construir bien.
A eso lo llamamos industrializar, no reescribir. La diferencia no es de vocabulario: es de método. Reescribir es volver a empezar con la información que tenías al principio. Industrializar es conservar lo aprendido, rehacer lo que no aguanta y añadir lo que falta, por fases y en el orden correcto.
Y el orden correcto casi nunca coincide con las ganas. La tentación es empezar por las funcionalidades nuevas, que es lo divertido. La primera fase debería atacar siempre lo que impide usar el sistema con seguridad: datos, permisos y continuidad. Lo demás puede esperar; eso no.
Cómo saber en qué estado estás de verdad
No se puede decidir esto por intuición, ni tampoco pidiéndole a la propia IA que se autoevalúe. Hace falta que alguien con experiencia mire el sistema con los ojos con los que lo miraría un auditor, y te lo cuente en lenguaje de negocio.
Eso es lo que hacemos en nuestra auditoría de prototipo IA: una semana de trabajo, precio cerrado y un informe con seis cosas dentro.
- Qué se conserva, con porcentajes honestos. Va siempre primero, porque es lo primero que hay que saber.
- Un semáforo por áreas: seguridad, datos, continuidad, mantenibilidad, cumplimiento legal y rendimiento.
- Los riesgos ordenados por gravedad, cada uno con su consecuencia expresada en términos de negocio, no de código.
- El plan por fases, priorizado por riesgo.
- El presupuesto cerrado de la primera fase, para que puedas decidir con un número real delante.
- Una sesión de una hora para explicártelo y responder a todo.
Es un diagnóstico, no una obra. Y es deliberadamente un documento que puedes llevar a tu comité sin quedar mal: está escrito para justificar la decisión que tomaste, no para ridiculizarla.
Consejo Dediez: Pide siempre que el informe incluya explícitamente qué se conserva y en qué porcentaje. Si un proveedor solo sabe enumerarte defectos, no está evaluando tu sistema: está justificando su presupuesto.
En Dediez Software también usamos IA
Conviene decirlo claro, porque este artículo podría leerse como un alegato en contra y no lo es. Usamos herramientas de IA a diario, y nos han hecho más rápidos.
Lo que aportan quince años de oficio no es escribir el código más deprisa: es saber qué preguntas hay que hacerse antes de escribirlo, y responder de que el sistema siga funcionando dentro de tres años. Ese es exactamente el punto ciego de cualquier herramienta que trabaja a partir de lo que se le pide, porque el problema de fondo es que no sabes qué pedir.
La IA hace muy bien el 80 % que se ve. Nosotros hacemos el 20 % que sostiene. Y con tu prototipo por delante, ese 20 % es un proyecto mucho más corto, más barato y más seguro de lo que te imaginas.
Has validado tu idea de la única forma que funciona de verdad: construyéndola y usándola. Lo que falta ahora no es empezar otra vez, es terminarlo bien.
Cuéntanos qué has montado y en una semana sabrás exactamente qué aguanta, qué no y cuánto cuesta llevarlo a producción.