TL;DR: Rehacer una app mal construida cuesta entre 1.5x y 3x lo que costó la versión original, dependiendo de cuánta deuda técnica acumuló. A veces conviene la reescritura total; otras, una refactorización progresiva. Lo más caro no es el código: es el tiempo perdido en el mercado.
Cuánto cuesta rehacer una app mal hecha
"Encontré a alguien que me la hace por la mitad" es una frase que precede a muchas historias de dolor. No siempre, pero con suficiente frecuencia como para que valga la pena entender qué pasa cuando una app se hace mal y qué implica arreglarlo.
Puntos clave
- Una app "mal hecha" puede funcionar en apariencia pero ser imposible de mantener o escalar
- Las señales de deuda técnica grave: bugs constantes, imposibilidad de agregar funcionalidades, dependencias desactualizadas críticas
- Hay dos caminos: refactorización progresiva (más barata, más lenta) o reescritura total (más cara, más rápida de ejecutar)
- Una reescritura total cuesta entre 1.5x y 2.5x el costo original
- El costo real más alto es el tiempo perdido en el mercado mientras el producto no evoluciona
¿Qué significa "una app mal hecha"?
Una app puede verse bien y funcionar aparentemente bien para el usuario final, pero estar construida de formas que generan problemas graves a mediano plazo:
Código sin estructura (spaghetti code): Lógica entremezclada sin separación de responsabilidades. Cambiar una cosa rompe otra en un lugar completamente diferente.
Sin tests: No hay pruebas automatizadas. Cada cambio puede introducir bugs que nadie detecta hasta que los reporta un usuario.
Dependencias desactualizadas o deprecadas: La app fue construida con versiones viejas de frameworks o librerías que ya no reciben soporte de seguridad.
Sin documentación: Nadie que no sea el desarrollador original entiende cómo funciona el sistema. Cuando ese desarrollador no está disponible, el proyecto queda paralizado.
Arquitectura no escalable: Funciona para 50 usuarios pero se cae con 500.
Seguridad deficiente: APIs que exponen datos que no deberían, tokens de sesión mal manejados, inputs sin validación.
Las señales de alerta en tiempo real
¿Cómo sabés si tu app tiene este problema? Estas son las señales más comunes:
- Los bugs aparecen más rápido de lo que se arreglan. Cada corrección introduce dos nuevos problemas.
- Agregar una funcionalidad nueva tarda el doble de lo esperado. Los desarrolladores dicen que "hay que revisar todo para no romper nada".
- Cambiaste de desarrollador y el nuevo no puede entender el código. El código antiguo es ilegible para cualquiera que no sea quien lo escribió.
- La app se cae o se pone lenta con más usuarios. No estaba diseñada para crecer.
- El equipo tiene miedo de tocar cierta parte del código. Hay módulos que nadie quiere modificar porque "nadie sabe qué puede pasar".
Las opciones cuando tenés una app mal hecha
Opción 1: Refactorización progresiva
Consiste en ir mejorando el código existente de forma gradual, módulo por módulo, sin detener el desarrollo de nuevas funcionalidades.
Ventajas:
- Menor costo puntual (se distribuye en el tiempo)
- La app sigue evolucionando mientras se mejora
- Menor riesgo de interrupciones del servicio
Desventajas:
- Proceso lento (puede tomar 6–12 meses o más)
- Mientras hay partes del sistema viejas, el riesgo de bugs persiste
- Requiere disciplina del equipo para no volver a acumular deuda
Cuándo conviene: Cuando la app tiene usuarios activos que no podés interrumpir, cuando el código tiene partes buenas mezcladas con partes malas, o cuando el presupuesto no permite una reescritura.
Costo: 20–40% sobre el costo normal de desarrollo, distribuido en el tiempo.
Opción 2: Reescritura total
Construir la app desde cero, esta vez bien. Se tira el código existente (o se usa solo como referencia funcional) y se empieza con arquitectura limpia.
Ventajas:
- Resultado final limpio y mantenible
- Mejor oportunidad para incorporar mejoras de UX y funcionalidades nuevas
- El equipo nuevo puede trabajar sin fricción del código heredado
Desventajas:
- Alto costo puntual
- Tiempo de desarrollo durante el cual el producto no evoluciona
- Riesgo de volver a cometer los mismos errores si no se cambia el proceso
Cuándo conviene: Cuando el código está tan degradado que cada cambio es más lento y costoso que reescribirlo, cuando hay un cambio tecnológico importante (por ejemplo, migrar a React Native de una app nativa antigua), o cuando el negocio va a escalar y la arquitectura actual no lo permite.
Costo: Entre 1.5x y 2.5x el costo de la versión original.
| Criterio | Refactorización progresiva | Reescritura total |
|---|---|---|
| Costo | 20–40% adicional, distribuido | 150–250% del costo original, puntual |
| Tiempo para ver mejoras | Gradual, 3–12 meses | 4–8 meses (duración del proyecto) |
| Interrupción del servicio | Mínima | Puede requerir freeze de funcionalidades |
| Resultado final | Mejora incremental | Código limpio desde la base |
| Riesgo | Proceso lento, puede desviarse | Alto costo, riesgo de reescribir errores |
| Mejor cuando | Hay partes rescatables, usuarios activos | El código es irrecuperable, hay cambio tecnológico |
El costo real: tiempo perdido en el mercado
El costo de reescritura en dinero es real pero no es el costo más alto. El costo más alto es el tiempo que el producto no evoluciona mientras se hace la reescritura.
Durante 4–6 meses de reescritura:
- No se agregan funcionalidades que los usuarios piden
- Los competidores siguen iterando
- El equipo no puede responder a oportunidades del mercado
Para un producto que compite activamente, esto puede ser más dañino que el costo del desarrollo en sí.
Cómo evitar llegar a esta situación
Antes de contratar:
- Pedí referencias de proyectos similares y hablá con esos clientes
- Exigí que el código quede en un repositorio de tu propiedad desde el inicio
- Pedí que incluyan tests en el alcance del proyecto
- No elijas solo por precio: el desarrollador más barato puede ser el más caro en el total
Durante el desarrollo:
- Hacé revisiones de código periódicas (code reviews)
- Revisá que el repositorio tenga actividad consistente y commits descriptivos
- Pedí demos funcionales periódicas, no solo informes de avance
Al recibir el proyecto:
- Exigí documentación técnica básica: cómo correr el proyecto, qué hace cada módulo
- Revisá que las dependencias estén actualizadas
- Pedí al menos algunos tests automatizados para los flujos más importantes
⚠️ Atención
Una app entregada sin tests, sin documentación y con dependencias desactualizadas no está "lista". Está en una fase de deuda técnica que va a costarte dinero en los próximos 12–24 meses. Es legítimo negociar esto como parte de los criterios de aceptación del proyecto.
Preguntas frecuentes
- Una reescritura total generalmente cuesta entre 1.5 y 2.5 veces lo que costó la versión original, porque el equipo necesita entender los requisitos del sistema existente, la arquitectura nueva requiere decisiones más cuidadosas, y hay que mantener el sistema viejo funcionando durante la transición. En proyectos de USD 20.000–40.000, la reescritura puede estar entre USD 30.000 y USD 80.000.
- Las señales más claras: los bugs aparecen más rápido de lo que se corrigen, agregar una funcionalidad nueva demora mucho más de lo esperado, los desarrolladores nuevos no pueden entender el código, la app se cae bajo carga que debería soportar, o el equipo tiene 'miedo' de tocar ciertas partes del código. Si reconocés dos o más de estas señales, probablemente tenés deuda técnica significativa.
- Depende del estado del código. Si hay partes rescatables y tenés usuarios activos que no podés interrumpir, la refactorización progresiva distribuye el costo y el riesgo. Si el código está tan degradado que cada cambio cuesta más que rehacerlo, o si hay un cambio tecnológico importante, la reescritura total puede ser más eficiente a largo plazo. Un buen arquitecto puede evaluar el código y darte una recomendación fundada.
- Sí, pero el costo de onboarding depende mucho de la calidad del código heredado. Con documentación buena y código limpio, un equipo nuevo puede estar productivo en 2–4 semanas. Con código sin documentar y sin estructura, puede tomar 2–3 meses de 'arqueología' antes de poder hacer cambios seguros. Este es uno de los riesgos concretos de no exigir documentación y tests desde el inicio.
- Cuatro cosas concretas en el contrato: 1) El repositorio de código queda en una cuenta de tu propiedad desde el día uno. 2) El proyecto incluye al menos tests de integración para los flujos principales. 3) Se entrega documentación técnica básica: cómo correr el proyecto y descripción de la arquitectura. 4) Las dependencias usadas son versiones con soporte activo al momento de la entrega.