Respuesta directa
Busca a alguien que revise antes de prometer. La señal decisiva no es que te diga que puede terminarlo: es que te explique qué va a conservar, qué va a rehacer y por qué, después de haber mirado el código.
De dónde viene esta situación
Cada vez llegan más proyectos con el mismo perfil: alguien con una idea clara ha construido un prototipo con herramientas de IA, funciona lo bastante como para enseñarlo, y se atasca justo cuando hay que ponerlo delante de usuarios reales.
No es un fracaso. Es exactamente para lo que sirven esas herramientas: llegar rápido a algo tangible sin gastar meses. El problema es que un prototipo que demuestra una idea y un sistema que puede tener usuarios, datos y pagos son cosas distintas.
Qué material conviene reunir antes de pedir presupuesto
Cuanto más ordenado llegue esto, mejor será la valoración que recibas:
- El código, con acceso de lectura al repositorio si existe.
- Dónde está desplegado y con qué servicios externos habla.
- Qué datos guarda y de quién.
- Qué funciona hoy y qué no.
- Qué es imprescindible para la primera versión real y qué puede esperar.
Ese último punto lo decides tú, no el desarrollador, y es el que más influye en el resultado.
Señales de una revisión seria
Pide acceso antes de dar un número. Quien presupuesta un proyecto así sin mirarlo, o infla el precio para cubrirse, o pedirá ampliaciones a mitad de camino.
Distingue entre lo que funciona y lo que aguanta. Muchas cosas generadas funcionan en la demo y se rompen con veinte usuarios simultáneos, con un dato inesperado o con alguien que manipula lo que envía el navegador.
Pregunta por los datos. Qué se guarda, dónde, quién puede leerlo, qué pasa si alguien cambia un identificador en la URL. Si tu aplicación maneja datos personales, esta conversación tiene que existir desde el principio.
Habla de lo que no va a hacer. Una propuesta que solo enumera lo incluido está incompleta. Los límites importan tanto como el alcance.
Reconoce la incertidumbre. En un proyecto así hay partes que no se pueden estimar hasta abrirlas. Quien te da una cifra exacta para todo, no lo ha mirado.
Preguntas concretas que puedes hacer
No hace falta ser técnico para plantearlas:
- ¿Qué parte del código actual conservarías y cuál rehacerías?
- ¿Cómo se comprueba hoy que un usuario solo puede ver sus propios datos?
- ¿Qué pasa si el servicio externo del que depende deja de responder?
- ¿Cómo sabremos que algo se ha roto en producción?
- ¿Qué me quedaría si mañana dejamos de trabajar juntos?
La última es la más reveladora. La respuesta correcta incluye código, accesos, documentación mínima y capacidad de que otro continúe.
El error de saltarse la fase de revisión
He escrito antes sobre los errores al crear una web con inteligencia artificial, y en aplicaciones el patrón se repite amplificado: lo que en una web produce un problema de SEO o de accesibilidad, en una aplicación produce una fuga de datos.
La diferencia entre un prototipo y un producto no es cuánto código tiene. Es si alguien ha pensado qué ocurre cuando las cosas van mal: qué pasa con un formulario enviado dos veces, con un pago que falla a mitad, con un usuario que intenta acceder a lo que no le corresponde.
Cómo trabajo yo estos casos
Empiezo por una revisión acotada con un documento como resultado: qué hay, qué se aprovecha, qué riesgos existen y en qué orden conviene resolverlos. A partir de ahí decides tú, con información, si sigues conmigo, con otro o con nadie.
Nunca prometo un alcance cerrado antes de haber abierto el código. Es lo que espero de alguien que revisa mi trabajo, y me parece lo mínimo exigible.
Siguiente paso
Puedes ver el planteamiento completo en aplicaciones web y MVP, o contarme en qué punto está tu proyecto en el estudio de proyecto.