Software rewrite: la pregunta equivocada que cae sobre el founder no técnico en el peor momento

Una guía de campo para founders a quienes les están proponiendo financiar una reescritura de software: qué significa realmente la pregunta, por qué casi siempre falla, y las cuatro preguntas que deberías hacer antes de firmar nada.

Camila llevaba diecinueve meses como CEO cuando su dev líder entró a un 1:1 y dijo la frase que todo founder no técnico escucha tarde o temprano: “Tenemos que reescribir esto.” El producto tenía clientes reales, ingresos mensuales, y un cheque de inversor que había caído en febrero. El codebase tenía dieciocho meses, fue construido rápido durante el pre-seed, y mostraba las huellas de los cuatro contractors que pasaron por él. El dev quería seis meses y una hoja en blanco. El inversor esperaba nuevas features. Camila no tenía cómo saber si aquello era una decisión seria de ingeniería o la alergia de un dev junior al código que heredó.

Un software rewrite es la decisión de descartar un codebase existente y construir un reemplazo desde cero, normalmente porque el equipo cree que el sistema actual ya no puede evolucionar a la velocidad que el negocio necesita. Esa es la definición de manual. La definición honesta es más áspera: el rewrite es lo que se propone cuando alguien del equipo perdió la fe en el código y ya no puede separar el problema técnico del problema emocional.

Para un founder no técnico, la pregunta del rewrite casi nunca es la pregunta que debería responderse. Son tres preguntas apiladas, y responder a la equivocada es como una empresa en etapa temprana quema un año de runway reconstruyendo lo que ya tenía.

Por qué “¿deberíamos reescribir?” es la pregunta equivocada

El marco que el dev te entrega es binario. Mantienes el código viejo, o empiezas de cero. Ese marco es lo que hace que el rewrite se apruebe, porque las dos respuestas parecen decisiones y una de ellas suena a progreso.

En la práctica, ninguna de las dos es lo que el negocio necesita. El negocio necesita saber qué le está doliendo. El codebase es una de las posibles causas. Normalmente son cuatro: el sistema genuinamente no puede hacer lo que el cliente necesita (arquitectura); el equipo no puede entregar con seguridad (operacional); los ingenieros no quieren trabajar en el código (cultural); o el founder no puede ver lo que está pasando (visibilidad). Cada una pide una intervención distinta, y solo una de ellas es un rewrite.

Si aceptas el binario, ya perdiste la conversación. La pregunta no es “lo mantenemos o empezamos de cero.” La pregunta es: ¿qué resultado de negocio concreto está impidiendo el código actual, y cuál es el cambio más pequeño que lo resuelve?

Los tres problemas escondidos dentro de la pregunta del rewrite

Cuando un dev dice “tenemos que reescribir esto”, casi siempre está mezclando tres problemas distintos. Sepáralos antes de decidir nada.

El problema de negocio

Empieza aquí. Antes de cualquier conversación sobre código, nombra el resultado de negocio que el sistema actual está volviendo imposible. ¿Es entregar la próxima feature sin romper la anterior? ¿Es la latencia que te está costando un cliente flagship? ¿Es lanzar un nuevo tier de precio? ¿Es una auditoría de seguridad que necesitas pasar para cerrar enterprise? ¿Es ninguno de esos, y el problema real es que el dev está aburrido?

Hemos visto founders financiar rewrites de seis meses porque la velocidad de entrega había bajado, solo para descubrir seis meses después que la entrega seguía siendo lenta en el codebase nuevo. El problema original era un ambiente de staging que no existía y un proceso de deploy sin documentar. Ninguno de los dos requería un rewrite.

Si no puedes terminar la frase “si hacemos este rewrite, la empresa va a poder hacer X para la fecha Y y Z va a ser medidamente distinto”, no tienes un problema de negocio. Tienes una preferencia de ingeniería disfrazada de problema de negocio.

La hipótesis técnica

Una vez nombrado el problema de negocio, la pregunta siguiente es: ¿qué cambio técnico de hecho resuelve esto? Un rewrite es una opción. Rara vez es la más barata. Casi siempre es la más lenta. Y carga un riesgo específico que los cambios incrementales no cargan: el código nuevo tiene que alcanzar paridad de features con el viejo antes de que alguien pueda usarlo. Ese trabajo es invisible para clientes e inversores. Seis meses construyendo cosas que ya existen es una de las formas más caras que puede tomar el roadmap de una startup.

Para la mayoría de los codebases en etapa temprana, las hipótesis más baratas son: refactors dirigidos en dos o tres módulos específicos; un nuevo servicio que se encarga de la pieza rota mientras el sistema viejo sigue corriendo; un rewrite de una sola capa (capa de acceso a datos, capa de auth) en lugar de todo el stack; o arreglar el deploy, el monitoreo y el setup de tests para que el código existente sea más seguro de tocar. Casi ningún founder escucha estas opciones porque el dev que propuso el rewrite ya decidió la respuesta.

La apuesta falsable

El tercer problema es el que casi nunca se articula, y es el que separa las decisiones de ingeniería reales de las wishful. Toda propuesta de rewrite es una apuesta. Las apuestas tienen una condición de falsificación: una forma de saber, antes de empezar, qué significaría que la apuesta falló.

¿Cuál es la métrica que dice que este rewrite funcionó? ¿Es frecuencia de deploy? ¿Tasa de bugs por release? ¿Tiempo de onboarding de un nuevo ingeniero? ¿Tiempo para entregar una feature que toca tres módulos? ¿Latencia visible al cliente? Sea cual sea, tiene que ser medible hoy, medible en el sistema reescrito, y confiable desde el asiento del founder, sin necesidad de preguntarle al dev. Si la apuesta es “te vas a sentir mejor con el código”, estás financiando terapia, no ingeniería. Es la misma lógica que usamos para definir qué es realmente un MVP: sin una condición de falsificación, tienes un proyecto, no una apuesta.

La regla de Joel Spolsky, 25 años después

En 2000, Joel Spolsky escribió lo que aún es el ensayo más citado sobre el tema, Things You Should Never Do, Part I. Su tesis: reescribir desde cero es el peor error estratégico que una empresa de software puede cometer. Netscape perdió la guerra de los browsers contra Microsoft porque pasó tres años reescribiendo Communicator mientras IE entregaba. La frase que todo founder debería guardar del texto: “estás tirando tu liderazgo de mercado.”

Veinticinco años después, la regla sigue valiendo para el caso que Spolsky protegía: un producto en producción, con clientes reales, modelo de negocio funcionando, y un codebase curtido por años de edge cases. No reescribas eso. Refactóralo.

Lo que cambió es la situación que Spolsky no estaba abordando. Él escribía sobre Netscape. El codebase que entra por la puerta de Pixel Breeders en 2026 es más a menudo un MVP de dieciocho meses, construido por dos contractors y un stack no-code, que nunca fue ingenierizado para durar. No es un sistema probado en batalla. Es un prototipo que sobrevivió al contacto con clientes, y los patrones que Spolsky defendía no aplican todos.

Para ese codebase, la pregunta cambia. No es “¿deberíamos reescribir Netscape?” Es “el prototipo alcanzó product-market fit antes de que la ingeniería pudiera alcanzarlo. ¿Y ahora qué?” Esa pregunta tiene otra respuesta, y normalmente implica reconstruir piezas del sistema en paralelo mientras el original sigue corriendo. No es un rewrite completo. No es un refactor. Es algo intermedio, con la misma disciplina de falsificación que una apuesta de verdad.

Cinco preguntas que hacer antes de financiar un rewrite

Cuando la propuesta de rewrite caiga sobre tu mesa, pásalas en orden. La mayoría de los rewrites se cae en las preguntas 1, 2 o 3.

1. ¿Cuál es la pérdida de negocio concreta que este codebase está creando? Fuerza un número o una fecha. Ingreso perdido, clientes no conquistados, un deal en riesgo, un deadline regulatorio. “No podemos movernos rápido” no es respuesta. “Acme se negó a renovar porque el endpoint de export hace timeout en archivos arriba de 50MB, y eso son USD 180K de ARR” es respuesta.

2. ¿El dev puede nombrar el único cambio que arreglaría 80% de la pérdida? Pídele que describa la intervención más pequeña que aborda el problema nombrado. Si lo puede decir en un párrafo, el rewrite probablemente es la respuesta equivocada y lo que deberías financiar es ese cambio. Si no puede, esa es tu señal: el rewrite se está proponiendo por defecto, no como decisión.

3. ¿Quién está recomendando el rewrite, y cuánto tiempo lleva con el código? Los devs que heredan un codebase llegan al momento “deberíamos reescribir esto” después de unos tres meses. Es un patrón psicológico conocido, no necesariamente técnico. Los ingenieros senior que convivieron con un codebase durante dos años rara vez proponen rewrites. Proponen refactors dirigidos. Si el rewrite lo recomienda alguien que entró hace seis semanas y solo tocó un módulo, pondera la recomendación en la proporción justa.

4. ¿Es una sola fecha de entrega, o un sistema paralelo que tiene que converger con producción? La respuesta honesta casi siempre es la segunda. Los rewrites que corren como “vamos a parar de construir features durante seis meses y después cambiamos” tienen una tasa de éxito de ~10% según nuestra experiencia. Los que corren como “vamos a construir lo nuevo al lado de lo viejo, migrar una feature por vez, y apagar lo viejo cuando la migración esté completa” llegan cerca de 60%. El primer plan es algo que los ingenieros dicen. El segundo es algo que los ingenieros entregan.

5. ¿Cómo se ve “terminado”, y es medible desde el asiento del founder? Terminado no es “el código nuevo tiene paridad de features.” Terminado es “entregamos la feature X en N días en lugar de M días, y el cliente Y está usando el sistema nuevo en producción con la métrica Z.” Si el dev no puede definir terminado de una forma que un founder no técnico pueda verificar, el rewrite no tiene condición de término. Un proyecto sin condición de término no termina. Contrata más devs.

Cuándo un rewrite sí es la respuesta correcta

Puede serlo. Cuatro patrones específicos valen la inversión.

El primero es el MVP vibe-coded que encontró product-market fit. Lo vemos cada mes. Un founder entregó algo en ocho semanas usando un backend alojado, tres APIs de SaaS, y un puñado de features asistidas por LLM que no termina de entender. Funciona. El cliente paga. Y cada feature nueva rompe otra cosa, porque el sistema nunca fue diseñado para hacer lo que ahora tiene que hacer. En este caso, el “rewrite” se parece más a una primera construcción propiamente dicha. La regla de Spolsky no aplica porque no hay ingeniería funcionando para tirar a la basura; hay un prototipo que ahora debe ingenierizarse. El framework que usamos con founders no técnicos en esa decisión exacta trata esto como la transición natural de “lo que construimos para aprender” a “lo que construimos para escalar.”

El segundo es el cambio de plataforma que el modelo de negocio ahora exige. Lanzaste un app web; ahora necesitas un producto mobile-first porque la base de clientes se movió. Construiste sobre una base de datos que no aguanta el siguiente orden de magnitud. Elegiste un stack no-code y el próximo tier de precio cuesta más que reconstruir. Esos no son rewrites de preferencia. Son rewrites de aderencia.

El tercero es la puerta de seguridad o compliance. SOC 2, HIPAA, PCI, LGPD, GDPR. Algunos regímenes de compliance se alcanzan desde el código existente con esfuerzo auditable. Otros no. Cuando la arquitectura existente no puede pasar la auditoría sin cambios más profundos que los que el diseño original soporta, el rewrite es real, y el costo es el costo de hacer el negocio que ahora haces.

El cuarto es el ingeniero insustituible que renunció, dejando un codebase que nadie más puede leer. Es el caso más controvertido, porque la movida correcta suele ser contratar a un nuevo ingeniero para que aprenda el código en vez de reescribir. Pero existe un umbral. Cuando el codebase es lo suficientemente pequeño, la documentación es lo suficientemente mala, y los que sabían leerlo ya se fueron, a veces el costo de aprender es más alto que el costo de reconstruir con un equipo que pueda mantener lo nuevo. Es raro. Si suena a tu situación, busca una segunda opinión con alguien que no va a facturar el rewrite.

Una prueba de 4 semanas antes de financiar el rewrite

Si después de las cinco preguntas todavía lo estás considerando, no firmes el rewrite. Corre una prueba de cuatro semanas primero.

Elige la única feature o módulo más doloroso, ese que aparece cada vez que el equipo se queja del codebase. Elige la métrica de falsificación que acordaron en la pregunta 5. Dale al equipo cuatro semanas para refactorizar esa pieza en el lugar o extraerla a un servicio paralelo, y para demostrar mejora medible en la métrica.

Cuatro semanas valen aproximadamente USD 20K a USD 50K en tiempo de ingeniería para un equipo en etapa temprana, dependiendo de las tarifas. Un rewrite completo es seis a doce meses y USD 150K a USD 600K a las mismas tarifas, y eso es antes del costo de mantenimiento del segundo año que vas a heredar en lo que sea que se entregue. La prueba de cuatro semanas es la forma más barata posible de saber si el equipo puede cambiar este sistema, punto.

Si puede: el rewrite es la respuesta equivocada; sigue refactorizando. Si no puede: ahora tienes evidencia, no opinión, y la conversación sobre el rewrite puede ocurrir con todos mirando los mismos datos.

Preguntas frecuentes

¿Qué es un software rewrite? Un software rewrite es la decisión de descartar un codebase existente y construir un reemplazo desde cero. Normalmente reemplaza el código original en su totalidad, no pieza por pieza, y apunta a alcanzar paridad de features con el sistema viejo antes de que los clientes vean algo nuevo.

¿Cuándo es un rewrite la respuesta correcta? Rara vez. Los casos defendibles son: un MVP que encontró product-market fit y ahora necesita ser ingenierizado de verdad por primera vez; un cambio de plataforma exigido por el modelo de negocio; un régimen de compliance que la arquitectura original no alcanza; o un codebase imposible de mantener cuyos ingenieros originales se fueron. En cualquier otro caso, un refactor dirigido o un servicio paralelo es más barato y más rápido.

¿Cuánto cuesta un software rewrite? Para un producto en etapa temprana, un rewrite real suele correr seis a doce meses de ingeniería, lo que da aproximadamente USD 150K a USD 600K en EE.UU. y R$ 300K a R$ 1,2M en Brasil dependiendo del tamaño y la senioridad del equipo. Ese número no incluye el costo recurrente de mantenimiento de operar dos sistemas durante la migración ni el costo de oportunidad de las features no entregadas mientras el rewrite ocurre. El costo escondido de un rewrite es lo que dejas de construir mientras corre.

¿Reescribir o refactorizar? Refactoriza por defecto. El refactor es incremental, te deja entregar valor visible al cliente durante el trabajo, y tiene una tasa de éxito mucho más alta. Elige el rewrite solo cuando el código existente no puede alcanzar el destino por ningún camino incremental. La “regla del 3” (refactoriza cuando veas el mismo patrón tres veces) es una heurística interna útil, pero no se extiende a codebases enteros. Los rewrites de sistema completo no son refactors a escala; son otro tipo de apuesta, con otros modos de falla.

¿Por qué la mayoría de los software rewrites falla? Tres razones, en orden de frecuencia. No terminan antes de que el runway se acabe, porque la paridad de features es más trabajo del que el equipo estimó. Entregan sin que la métrica de falsificación se haya cumplido, así que nadie puede saber si el rewrite funcionó. Y cambian un conjunto de problemas por otro, porque el equipo que escribió el código original suele ser el equipo que escribió el rewrite, con los mismos supuestos.

Si estás leyendo esto en medio de una conversación sobre rewrite, lo más útil que puedes hacer mañana no es aprobar el rewrite. Es hacer la pregunta 1 y negarte a seguir adelante sin un número.