Un proyecto se detiene casi siempre por la misma razón: falta información que solo el negocio puede dar. El 22.4 por ciento de los proyectos de desarrollo se detiene esperando insumos del cliente, y esos proyectos tardan 182 por ciento más. Antes de decidir si terminar o abandonar, confirma qué información falta realmente.
La rapidez para empezar es justo lo que hace más fácil quedarse a medias. Construir la primera versión de una app con IA toma poco tiempo, así que arrancar no exige el mismo nivel de compromiso que antes. Eso significa que también es más fácil dejarla en pausa cuando aparece algo más urgente.
Lo que casi nunca se detiene por falta de capacidad técnica es la parte de tomar decisiones de negocio. Construir un sistema exige decisiones de negocio que solo el cliente puede dar: qué regla aplica, qué excepción existe, qué prioridad tiene un flujo. Sin esas respuestas, el equipo no puede avanzar con criterio, aunque técnicamente podría seguir escribiendo código.
El resultado es un proyecto que parece estar en pausa por falta de tiempo, cuando en realidad está en pausa porque nadie tomó las decisiones que le faltaban para avanzar.
La respuesta depende de qué tan vigentes siguen las decisiones tomadas cuando el proyecto se detuvo. Retomar un desarrollo a medias no es lo mismo que continuar donde quedó. El negocio pudo cambiar mientras el proyecto estaba detenido, y una decisión que tenía sentido hace seis meses puede ya no aplicar.
Hay una prueba práctica para decidir. Revisa cuánto tiempo tomaría entender el código existente y validar que las reglas siguen vigentes. Compara eso con el tiempo que tomaría construir de nuevo con lo que hoy sí está claro. Cuando revisar y actualizar lo que ya existe toma casi el mismo tiempo que construirlo de nuevo, rehacer suele salir más barato que heredar esa deuda.
Esto no es una regla universal. Un proyecto que se detuvo hace pocas semanas, con un alcance que sigue vigente, casi siempre vale la pena retomarlo. Uno que lleva un año detenido, construido sobre supuestos que el negocio ya cambió, probablemente cuesta más entenderlo que rehacerlo.
La decisión empieza por confirmar por qué se detuvo, no por revisar el código primero. Si fue por falta de información del negocio, esa información sigue pendiente hoy, y hay que resolverla antes de decidir cualquier otra cosa. Retomar sin resolver eso solo reproduce la misma pausa más adelante.
Si la información ya está disponible, la pregunta pasa a ser técnica: qué tan vigente sigue el trabajo hecho. Aquí conviene ser honesto sobre el sesgo natural a querer aprovechar lo ya construido, incluso cuando aprovecharlo cuesta más que empezar de cero.
Abandonar es una opción válida, no un fracaso que evitar a toda costa. Si el problema que la app resolvía ya no existe, o se resolvió de otra forma mientras el proyecto estaba detenido, la app ya no hace falta. Seguir invirtiendo tiempo solo por no admitirlo es el peor de los tres caminos.
El costo sigue corriendo aunque nadie lo vea en una factura. El tiempo ya invertido no se recupera dejando el proyecto indefinido, y cada mes que pasa el código y las decisiones tomadas se vuelven más difíciles de retomar.
El tiempo ya invertido no se recupera dejando el proyecto indefinido, y cada mes que pasa el código y las decisiones tomadas se vuelven más difíciles de retomar.
Hay un costo adicional, menos obvio. Mientras el proyecto sigue indefinido, la persona que más sabe sobre él sigue cargando con esa información en la cabeza, sin que nadie más la tenga. Si esa persona se va antes de que se tome una decisión, se pierde no solo el trabajo hecho, se pierde también el criterio para decidir qué hacer con él.
No decidir es, en la práctica, decidir dejar el costo abierto de forma indefinida. Poner una fecha para revisar el proyecto y tomar una decisión, aunque sea la de abandonarlo, cierra ese costo en vez de dejarlo correr sin control.
Definiendo el alcance completo antes de empezar y comprometiendo tiempos de respuesta claros para las preguntas que van a surgir durante el desarrollo. La mayoría de los proyectos detenidos no se detienen por falta de trabajo técnico, se detienen esperando una respuesta.
Esto significa asignar, antes de empezar, quién del lado del negocio va a responder preguntas durante el proyecto y en cuánto tiempo. Un proyecto sin ese compromiso claro tiene el mismo riesgo de detenerse que cualquier otro, sin importar qué tan rápido se pueda escribir el código. El 22.4 por ciento de los proyectos de desarrollo se detiene esperando insumos del cliente, y los que pasan por esa espera tardan 182 por ciento más.
El 22.4 por ciento de los proyectos de desarrollo se detiene esperando insumos del cliente, y los que pasan por esa espera tardan 182 por ciento más.
También ayuda revisar el progreso en puntos fijos, no solo cuando algo falla. Un chequeo cada dos o tres semanas revela si el proyecto está avanzando o si ya entró en la etapa de espera silenciosa que termina en un desarrollo a medias. Detectarlo temprano cuesta mucho menos que descubrirlo meses después.
Primero confirma por qué se detuvo. Si fue por falta de información del negocio, esa información sigue pendiente hoy y hay que resolverla antes de decidir si continuar. Si fue por un problema técnico de fondo, la pregunta cambia a si vale la pena rehacerla.
Si quieres evaluar tu propio caso antes de decidir, puedes usar una guía para decidir si retomar, rehacer o abandonar tu app. También puedes revisar cómo terminar una aplicación que quedó a medias, dentro de la guía completa de Progresus Apps sobre apps con IA sin método.