Refactorizar vs reescribir: elegir el camino más rápido hacia producción

Lo que realmente estás decidiendo (y qué significa “rápido")

La elección entre refactorizar y reescribir no trata tanto de cuál enfoque es más “correcto”, sino de qué camino te lleva a una versión estable en producción con menos riesgo y menos sorpresas.

Refactorizar significa conservar la app existente, pero mejorar cómo está construida. Cambias la estructura para que el código sea más fácil de entender, más seguro de modificar y menos propenso a romperse. Las funciones en su mayoría permanecen iguales, pero el interior queda más limpio.

Reescribir implica empezar desde cero con una nueva base de código. Recreas la app tomando la versión vieja como referencia. Esto puede parecer más rápido porque dejas de pelear con problemas antiguos, pero también pierdes mucho aprendizaje ganado sobre casos límite.

El objetivo real no es código perfecto. El objetivo real es una versión que funcione para usuarios reales: inicios de sesión que no fallen, pagos que no cobren doble, datos que no desaparezcan y actualizaciones que no introduzcan nuevos bugs.

Cuando la gente dice “más rápido”, normalmente quiere una de estas cosas:

• Tiempo calendárico rápido (qué tan pronto puedes lanzar algo usable)
• Rápido con bajo riesgo (qué tan probable es lanzar sin un incendio en producción)
• Rápido a largo plazo (cuánto re-trabajo evitas después del lanzamiento)

La trampa es optimizar solo para lo primero. Lanzar en 10 días no ayuda si luego pasas 6 semanas arreglando interrupciones, parchando agujeros de seguridad y reconstruyendo funciones que omitiste.

Un ejemplo común: un prototipo generado por IA parece terminado, pero oculta problemas como secretos expuestos, manejo de datos desordenado o autenticación frágil. Un refactor rápido puede parchear lo obvio y sacar una demo, pero si la base es inestable, terminas “refactorizando para siempre”. Equipos como FixMyMess ven esto a menudo con apps generadas en herramientas como Lovable, Bolt, v0, Cursor o Replit.

“Rápido ahora” se vuelve “lento después” cuando:

• Sigues añadiendo funciones a código que no puedes cambiar con confianza
• Omite pruebas, de modo que cada cambio rompe algo inesperado
• Arrastras patrones inseguros a producción (consultas inseguras o claves filtradas)
• Dependes de una sola persona que entiende el desastre

Una buena decisión hace que velocidad y estabilidad trabajen juntas: lanza pronto, pero no de una forma que cree un segundo proyecto más largo justo después del lanzamiento.

Señales de salud del código que favorecen el refactor

Refactorizar suele ser el camino más rápido cuando el código ya tiene una columna vertebral en la que puedes confiar. En la decisión refactor vs reescribir, buscas una base de código que en su mayoría tenga sentido, aunque sea desordenada.

La “forma” del código está clara

Un buen candidato a refactorizar tiene estructura visible: carpetas que coinciden con características, archivos con una sola responsabilidad y la app sigue un patrón consistente (aunque no sea tu patrón favorito). Puedes seguir una acción de usuario desde la UI hasta la API y la base de datos sin perderte.

También verás límites que pueden sostenerse: un módulo de autenticación claro, una zona de pagos separada o una capa de datos definida. Eso hace posible mejorar una parte sin romper todo.

Los puntos de dolor son solucionables, no fundamentales

El refactor brilla cuando los problemas son locales y repetibles. Señales típicas incluyen lógica duplicada, archivos demasiado largos, manejo de errores ausente y problemas de configuración «funciona en mi máquina». Son molestos, pero no significan que todo el sistema esté confundido.

Busca bugs que se concentren en características específicas en lugar de aparecer por todas partes. Si el inicio de sesión está roto pero el resto de la app se comporta, eso indica refactor. Si cada cambio provoca fallos aleatorios en pantallas no relacionadas, estás más cerca del territorio de reescribir.

Aquí hay indicadores rápidos y fáciles de ver que favorecen el refactor:

• Uno o dos “puntos calientes” causan la mayoría de los problemas (por ejemplo, auth o un único modelo de datos)
• Los nombres son mayormente legibles y el flujo se sigue con registros básicos
• Las mismas correcciones se repiten (validación faltante, respuestas de API inconsistentes)
• Las dependencias son razonables y lo suficientemente actualizadas para parchear
• Los problemas de rendimiento están ligados a consultas o endpoints específicos

Los problemas de escalado y velocidad también pueden ser buenos objetivos de refactor cuando puedes mejorarlos paso a paso: agregar caché a un endpoint, optimizar una consulta SQL lenta o mover trabajo pesado a un job en segundo plano.

Ejemplo: un fundador trae una app generada por IA donde el onboarding funciona, pero las páginas de facturación están desordenadas y hay secretos expuestos en el repo. Un equipo como FixMyMess típicamente refactorizaría: contener las partes riesgosas, endurecer la seguridad, limpiar el flujo de cobros y mantener lo que ya funciona.

Señales que hacen la reescritura la opción más segura

A veces el camino más rápido es dejar de parchear y empezar de nuevo. En la elección refactor vs reescribir, “más seguro” suele significar que puedes predecir lo que pasará tras cada cambio y que puedes lanzar sin una cola larga de sorpresas.

Bloqueadores difíciles que no puedes desenredar

Una reescritura suele ser más segura cuando el código no tiene límites claros. Se nota cuando un cambio rompe tres áreas no relacionadas, o cuando no puedes explicar cómo fluyen los datos por la app sin leerlo todo.

Señales comunes de “bloqueador difícil”:

• Dependencias ajustadas y entrelazadas donde cada archivo importa a casi todos los demás
• Efectos secundarios por todas partes (estado global, jobs ocultos, configuración mágica)
• Ninguna fuente única de verdad para los datos (almacenes múltiples en competencia, lógica duplicada)
• “Fijar” algo requiere tocar docenas de archivos para una pequeña característica
• Una configuración de build o deploy que solo funciona en una máquina

Si no puedes aislar un punto de partida seguro, refactorizar se convierte en una búsqueda lenta de minas terrestres.

Fallos repetidos y señales de seguridad

Si el mismo tipo de bug vuelve una y otra vez, suele apuntar a un diseño roto, no a un parche faltante. Repeticiones típicas incluyen autenticación que falla tras cambios menores en la UI, bugs de estado que aparecen después de unos clics y integraciones frágiles que dependen de comportamientos no documentados.

Los problemas de seguridad también pueden forzar una reescritura. Secretos expuestos en el repo, consultas a la base de datos inseguras, permisos demasiado amplios o checks de auth copiados y pegados no son problemas «para después». Cambian la ecuación de riesgo porque puede que no puedas demostrar que el sistema es seguro sin reemplazar las partes riesgosas.

Un ejemplo rápido: una app prototipo funciona en demos, pero los usuarios se desconectan aleatoriamente, el webhook de pago falla en reintentos y encuentras claves de API en código cliente. Puedes pasar semanas persiguiendo síntomas o reconstruir los flujos centrales con límites claros y valores por defecto más seguros.

Finalmente, si los requisitos han cambiado tanto que el diseño original ya no encaja (por ejemplo, se diseñó para un solo usuario y ahora necesita equipos, roles y registros de auditoría), reescribir puede ser más rápido que forzar una nueva realidad en una base vieja.

Este es el tipo de situación que FixMyMess suele ver en bases de código generadas por IA: la app “funciona en su mayoría”, pero la base hace que cada arreglo sea riesgoso. Una reescritura limpia del núcleo puede ser la ruta más rápida a producción cuando la estructura actual no es confiable.

Cobertura de pruebas: el factor que cambia la matemática del riesgo

Si refactorizas código sin pruebas, estás cambiando partes con los ojos vendados. Puede que funcione cuando pruebas una vez, pero el siguiente cambio puede romper algo que no notaste.

Las pruebas son la red de seguridad que te dice: "la app todavía hace lo que los usuarios necesitan." Con esa red, trabajar en refactor suele ser más rápido y seguro que reescribir, porque puedes mejorar el sistema existente en pasos pequeños y detectar errores temprano.

Por qué la baja cobertura de pruebas hace tentadora la reescritura

Cuando hay pocas o ninguna prueba, cada cambio se convierte en una comprobación manual. Eso se transforma rápidamente en largos ciclos de “arregla una cosa, rompe otra.” En esa situación, los equipos a menudo se inclinan por reescribir porque empezar de cero se siente más limpio.

Pero la baja cobertura no significa automáticamente reescribir. A menudo el movimiento más rápido es “refactor con pruebas primero”: añade un pequeño conjunto de pruebas alrededor del comportamiento más importante y luego refactoriza protegido por esa barrera. Una reescritura sin pruebas también puede fallar, porque aún no tienes una forma rápida de demostrar que la nueva versión cumple los requisitos viejos.

Las formas más rápidas de ganar confianza (sin hacerlo todo)

No necesitas cobertura perfecta para reducir riesgo. Necesitas cobertura donde las fallas dolerían.

Empieza con algunas comprobaciones ligeras:

• Pruebas de humo: ¿la app carga, se puede iniciar sesión y llegar a la pantalla principal?
• Pruebas de ruta crítica: las 3-5 acciones que hacen o ahorran dinero (registro, checkout, crear pedido, enviar mensaje)
• Pruebas de regresión de bugs: una prueba por cada bug doloroso que arreglaste para que no vuelva
• Pruebas de auth y permisos: el lugar más sencillo para sorpresas y problemas de seguridad

Luego añade profundidad solo donde compense.

Pruebas unitarias vs end-to-end en términos simples: las unitarias verifican partes pequeñas (una función o módulo) y corren rápido. Las end-to-end simulan un usuario real navegando la app y detectan problemas de "funciona todo junto", pero corren más lentas y pueden ser frágiles.

Una regla práctica: usa unas pocas pruebas end-to-end para cubrir la ruta crítica y tests unitarios para asegurar la lógica delicada.

Si heredaste un prototipo generado por IA (de herramientas como Lovable, Bolt, v0, Cursor o Replit), es común no tener casi ninguna prueba. En ese caso, una evaluación rápida de salud del código más un conjunto pequeño de pruebas de ruta crítica suelen decirte si refactorizar o reescribir es la apuesta más segura, sin adivinar.

Cronogramas y riesgo: cómo estimar sin adivinar

Cuando la gente debate refactor vs reescribir, a menudo discuten sobre rapidez. La pregunta real es: qué tan rápido puedes lanzar una primera versión de producción confiable sin apostarlo todo a una suposición.

Una forma simple de estimar es convertir el proyecto en una lista de “cosas que deben funcionar el día uno”. Empieza con un inventario y añade márgenes para lo que aún no puedes ver.

Un método simple de estimación

Anota cada característica y cada integración imprescindible, luego etiqueta cada una como conocida, difusa o desconocida.

• Características: login, onboarding, flujos principales, admin, facturación
• Integraciones: pagos, email/SMS, analítica, SSO, webhooks
• Desconocidos: requisitos poco claros, documentación faltante, datos inconsistentes, configuraciones “funciona en mi máquina”
• Reductores de riesgo: pruebas existentes, entorno de staging, capacidad de ejecutar la app localmente
• Restricciones duras: fecha de lanzamiento, requisitos de cumplimiento, revisión de app store, plazos de socios

Ahora da a cada ítem un rango de tiempo (no un solo número). Por ejemplo: “Stripe checkout 0.5 a 2 días” si conoces lo básico pero no los casos límite.

El riesgo de refactorizar suele aparecer como regresiones ocultas. Cambias algo pequeño y una característica distante se rompe porque el código está enredado. El riesgo de reescribir es distinto: reconstruyes rápido y luego descubres que omitiste alcance importante como migración de cuentas, roles y permisos o una integración complicada.

La parte más difícil son los “desconocidos desconocidos” — problemas que ni siquiera sabes listar todavía. Ponlos en el precio a propósito. Una regla práctica: añade un buffer de contingencia del 20% si el sistema es familiar y estable, 40% si está desordenado o poco entendido, y 60% si es un prototipo generado por IA con poca documentación.

Estrategia de fechas límite que te mantiene honesto

Separa “lanzamiento MVP a producción” de “mejorarlo después”. El MVP debe incluir solo lo necesario para llevar usuarios reales con seguridad (básicos de seguridad, logging, backups y ruta de soporte). Mejoras como arquitectura perfecta, dashboards extra y características agradables van en una segunda fase.

Ejemplo: si tu app actual ya maneja auth y pagos pero el código es difícil de cambiar, un refactor focalizado con buenas pruebas de humo puede alcanzar el MVP más rápido. Si el auth está roto, los secretos están expuestos y el modelo de datos cambia constantemente, una reescritura con alcance MVP ajustado suele ser la línea de tiempo más segura. Equipos como FixMyMess suelen empezar mapeando estos riesgos en una auditoría rápida para que la estimación se base en lo que realmente hay en el código, no en la esperanza.

Paso a paso: un flujo de decisión práctico

Cuando estás atascado entre refactorizar y reescribir, necesitas una forma repetible de decidir que no dependa del instinto. Este flujo mantiene el foco en el comportamiento en producción, el riesgo y el tiempo.

Empieza por escribir lo que la app debe hacer en producción. Manténlo concreto y orientado al usuario: registrarse e iniciar sesión, restablecer contraseña, checkout, emails, acciones de admin y cualquier integración que no deba romperse. Si no está en esta lista, no está impulsando la decisión.

Luego recorre el código y mapea las mayores fallas a dónde ocurren. Elige los cinco problemas que bloquean el lanzamiento (no los que solo molestan). Para cada uno, anota el archivo o módulo, con qué frecuencia falla y qué pasa cuando falla (pérdida de datos, riesgo de seguridad o solo mala UX).

Usa una tarjeta de puntuación simple para evitar discutir en círculos. Califica estas tres áreas del 1 al 5: claridad del código (¿alguien puede seguir el flujo?), cobertura de pruebas (¿las rutas críticas están protegidas?) y conceptos básicos de seguridad (secretos, auth, validación). Los puntajes bajos no significan automáticamente reescribir, pero cambian la matemática del riesgo.

Aquí hay una secuencia práctica que funciona en la mayoría de equipos:

1. Define los comportamientos que deben funcionar y la barra mínima aceptable de rendimiento y seguridad.
2. Lista los cinco bloqueadores principales del lanzamiento y señala los lugares exactos en el código donde ocurren.
3. Puntúa la salud del código, las pruebas y la seguridad del 1 al 5, y escribe una frase explicando cada puntuación.
4. Elige un camino: refactoriza si la mayoría de los bloqueos son locales y entendibles, reescribe si las fallas son sistémicas o haz un híbrido reconstruyendo una porción completa end-to-end.
5. Fija una fecha de control con criterios de aprobado/rechazado (por ejemplo: login funciona, pagos tienen éxito, no hay secretos expuestos y las pruebas de humo pasan) antes de comprometerte completamente.

Un ejemplo rápido: una startup tiene una UI funcional, pero el login falla aleatoriamente, los emails son poco fiables y los secretos están hardcodeados. Si las fallas están mayormente en un módulo de auth y un helper de email desordenado, un refactor focalizado más arreglos de seguridad puede lanzar antes. Si el auth está enredado por todo el código sin pruebas y con modelos de datos inconsistentes, un plan híbrido (reescribir auth y flujo de datos de usuarios primero) suele ser más seguro.

Si heredaste un prototipo generado por IA, este es exactamente el tipo de clasificación que FixMyMess hace durante una auditoría de código gratuita: identificar bloqueos, puntuar riesgo y recomendar la ruta más rápida que aguante en producción.

Escenarios de ejemplo que puedes mapear a tu proyecto

Los proyectos reales rara vez parecen casos de libro limpio. Usa los escenarios siguientes para detectar el patrón que coincide con lo que tienes y luego ajusta según tu cronograma y tolerancia al riesgo.

Escenario A: El prototipo generado por IA funciona en una demo, pero falla en producción (auth falla, secretos expuestos, arquitectura enredada). Decisión: Refactorizar y reparar primero, porque lo más rápido suele ser arreglar las partes inseguras y frágiles sin tirar la UI y los flujos que ya funcionan.

Un caso común es una app construida en Lovable/Bolt/v0/Cursor/Replit que “funciona en su mayoría” hasta que usuarios reales se registran y los datos empiezan a fluir. Si la autenticación es inestable, las variables de entorno están hardcodeadas y el código está en un solo archivo, la reescritura completa puede resultar tentadora, pero a menudo retrasa al equipo mientras reaprende los mismos requisitos. La ganancia más rápida es asegurar secretos, arreglar auth, desenredar los peores módulos y añadir pruebas básicas alrededor del login y las acciones centrales. (Este es el tipo de rescate para el que existe FixMyMess.)

Escenario B: Una app madura tiene un núcleo estable, pero el trabajo de nuevas funciones se vuelve más lento cada mes. Decisión: Refactor focalizado, porque el producto está probado y el dolor es mayormente de mantenibilidad, no de corrección.

Aquí la app funciona, los clientes dependen de ella y el mayor problema es “cada cambio rompe algo”. Enfócate en los puntos calientes: un módulo lento, una cadena de dependencias desordenada, un área con bugs repetidos. Refactoriza en rebanadas pequeñas y mide el progreso por “tiempo para lanzar una pequeña función”, no por cuánto código tocaste.

Escenario C: Un pivot de producto cambió el modelo de datos y los flujos (nuevo pricing, nuevas entidades, nuevos permisos). Decisión: Reescritura selectiva, porque forzar una nueva realidad en un modelo de datos viejo crea infinitos casos límite.

Conserva lo que aún encaja (sistema de diseño, integración con proveedor de auth, reporting) y reescribe las partes que codifican la lógica de negocio antigua (esquema de datos, flujos centrales). Esto evita reescribir todo mientras eliminas la mayor fuente de bugs futuros.

Escenario D: Sin pruebas, muchos casos límite y una fecha límite ajustada. Decisión: Enfoque híbrido, porque refactor vs reescribir es menos importante que reducir riesgo rápido.

Congela el alcance, añade una delgada “cinturón de seguridad” de pruebas alrededor de las 3 principales rutas de usuario y luego arregla las fallas más peligrosas. Si una sección es demasiado arriesgada de tocar, reescribe esa pieza detrás de un feature flag o endpoint paralelo y cámbiala cuando pase las nuevas pruebas.

Errores comunes que desperdician semanas

La mayor pérdida de tiempo en una decisión refactor vs reescribir es creer que puedes hacer grandes cambios con seguridad sin saber qué puede romperse. Si no puedes verificar, rápidamente, si registro, login, checkout y emails siguen funcionando tras un cambio, cada paso se vuelve una prueba manual lenta.

Error 1: Refactorizar sin pruebas y llamarlo “seguro”

Refactorizar puede ser más rápido, pero solo si tienes una red de seguridad básica. Sin pruebas (o al menos un pequeño conjunto de comprobaciones repetibles), terminas haciendo el mismo trabajo dos veces: primero mejoras el código y luego buscas los bugs que el refactor introdujo.

Una solución simple: antes de tocar la arquitectura, escribe un puñado de comprobaciones de alto valor para los flujos que hacen real a la app. Piensa “¿puede un nuevo usuario registrarse, pagar y recibir una confirmación?”.

Error 2: Reescribir mientras los requisitos están cambiando

Las reescrituras atraen ideas cambiantes. Cuando la dirección del producto cambia cada pocos días, la reescritura nunca “termina”. Sigues reconstruyendo la base mientras el plan del edificio cambia.

Si debes reescribir, congela lo imprescindible para la primera versión y mueve los extras a una segunda pasada. Incluso una definición de hecho de una página puede ahorrar semanas.

Aquí hay áreas de integración que los equipos suelen olvidar contar al estimar:

• Pagos (webhooks, reintentos, casos límite como reembolsos)
• Emails/SMS (entregabilidad, plantillas, baja de suscripción)
• Analítica (eventos, identidad de usuario, privacidad)
• Permisos/roles (admin vs usuario, acceso a datos)
• APIs de terceros (límites de tasa, manejo de errores)

Error 3: Dejar seguridad y confiabilidad para el final

Los problemas de seguridad no son una tarea “para después”. Secretos expuestos, auth débil y riesgos de inyección pueden forzar retrabajo tardío porque tocan flujos centrales. Lo mismo aplica a problemas de confiabilidad como ausencia de límites de tasa, falta de validación de entrada o jobs frágiles.

Ejemplo: un equipo lanza un dashboard reescrito y luego descubre que su webhook de pago puede ser suplantado. Ahora deben rehacer auth, auditar datos y parchear producción apresuradamente.

Error 4: Pulir estilo de código mientras producción sigue rota

Se siente bien renombrar archivos y ordenar carpetas. Pero si la app no se despliega limpiamente, se bloquea con datos reales o tiene autenticación rota, limpiar estilo es una distracción.

Si heredaste código generado por IA, los equipos a menudo se quedan atrapados en este bucle. Plataformas como FixMyMess se enfocan primero en el diagnóstico (qué está realmente roto), luego en reparaciones dirigidas para alcanzar producción sin convertirlo en un proyecto interminable de “mejoras”.

Lista rápida antes de comprometerte

Antes de elegir refactorizar o reescribir, haz una verificación rápida de la realidad. Esto es menos sobre opiniones y más sobre si el código actual puede cambiarse con seguridad sin sorpresas.

Cinco preguntas que revelan el riesgo real

Empieza con estas comprobaciones y responde con un sí o no. Si no puedes responder, considéralo un “no” hasta que se pruebe lo contrario.

• ¿Alguien puede explicar la ruta principal de datos desde la acción del usuario hasta la base de datos y de vuelta, sin evasivas?
• ¿Tienes pruebas automatizadas para las tres acciones que más importan (por ejemplo: registrarse, iniciar sesión y checkout o crear proyecto)?
• ¿Hay algo obviamente inseguro ahora mismo (claves de API hardcodeadas, rutas admin abiertas, auth débil, consultas SQL inseguras)?
• ¿Cuántos servicios externos deben funcionar el día uno (pagos, email, analítica, almacenamiento de archivos)?
• ¿Podría un desarrollador nuevo abrir el repo y entender la estructura en 1 a 2 horas?

Si respondiste “no” a un ítem, aún puedes refactorizar, pero tu estimación debe incluir tiempo para reducir ese riesgo (añadir pruebas, mapear flujos, arreglar seguridad). Si respondiste “no” a tres o más, reescribir a menudo se vuelve el camino más rápido porque estás pagando una “tasa de descubrimiento” en cada cambio.

Una forma rápida de interpretar tus respuestas

Imagina un escenario simple: un fundador tiene un prototipo creado con una herramienta de IA y el login funciona localmente pero falla en producción. Si no hay pruebas, el flujo de datos es poco claro y los secretos están expuestos, cada arreglo puede romper otra cosa. En casos así, los equipos suelen pasar días persiguiendo síntomas.

Aquí es donde una auditoría corta ayuda. En FixMyMess vemos el mismo patrón en apps generadas por IA: lógica de autenticación pegada, secretos cometidos en el repo e integraciones que se comportan distinto en producción. Cuando eso aparece junto, la decisión “rápida” más segura es la que reduce primero los desconocidos, aunque parezca mayor en el papel.

Toma tu decisión solo después de poder explicar: qué debe funcionar el día uno, qué puede esperar y qué puedes verificar con pruebas.

Próximos pasos: decide y llega a producción

Elige el lanzamiento más pequeño que puedas enviar y define “hecho” en términos claros. No “el código está más limpio” o “la arquitectura es moderna”, sino resultados como: los usuarios pueden registrarse, pagar y completar la acción principal sin errores. Un objetivo más pequeño facilita la decisión refactor vs reescribir porque puedes juzgar qué camino llega a esa meta con menos riesgo.

Escribe tu definición de “hecho” como una lista corta que puedas probar en una sola sesión:

• Flujo de usuario central funciona end to end (ruta feliz)
• Login, pagos y emails se comportan correctamente
• No hay secretos expuestos y pasan las comprobaciones básicas de seguridad
• La app se despliega de forma fiable en tu entorno real

Si tu app fue generada por una herramienta de IA y falla en producción, empieza con un diagnóstico antes de comprometerte con cualquiera de las dos rutas. Los prototipos generados por IA a menudo parecen completos pero ocultan problemas como autenticación rota, lógica enmarañada y consultas inseguras. Arreglar eso a ciegas puede convertirse en semanas de conjeturas.

Una opción práctica es obtener una auditoría experta primero. FixMyMess (fixmymess.ai) ofrece una auditoría de código gratuita para identificar qué está roto, qué es riesgoso y qué puede salvarse. Muchas remediaciones se completan en 48-72 horas una vez que los problemas están claros. Y si el prototipo está muy roto, una reconstrucción limpia puede ser más rápida que parchear alrededor de código frágil, a veces tan rápida como 24 horas para un alcance bien enfocado.

Aquí tienes una forma simple de avanzar hoy: imagina que necesitas un onboarding funcional para el viernes. Si el código actual ya tiene las pantallas, el enrutamiento y el modelo de datos, refactorizar más arreglos focalizados puede llevarte allí. Si las acciones básicas fallan, el estado es inconsistente y no puedes confiar en lo que romperá el siguiente cambio, reescribir la porción mínima enviable suele ser más seguro.

Si quieres una recomendación clara, comparte tu cronograma, qué significa “hecho” y qué está fallando ahora. Obtendrás una decisión directa sobre refactorizar, reescribir o hacer un plan híbrido rápido que te lleve a producción.